You asked:
> Is it possible you are running out of disk space on the /tmp directory??
I don’t think so. Big Brother is watching this system and the “disk usage” report has been “green” for the last 119.52 days!
/tmp would have been flagged “yellow” if it’s free space had dropped below 10% for more than 5 minutes. Right now it’s:
[EMAIL PROTECTED] ntop]# df -k /tmp
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda7 1004024 16456 936564 2% /tmp
Any other idea?
Thanks for your help,
Marc.
le 05/08/24 11:11, Burton Strauss à [EMAIL PROTECTED] a écrit :
I don't think is this related... There is certainly no magic number stuff in the log extract. Hence the change in message subject.
The fact that you were trying to return a graph could be significant for an unrelated problem.
FWIW, the alarm() message usually means a loop, although it has been know to occur if there are 10000s of hosts and it really just does take that long to create the page (usually because of insufficient memory - swapping as ntop walks the structure building the list and then again as it creates the page).
While it's certainly possible that the alarm() simply happened to be tripped at that point, it's odd ... drawTrafficPie() is relatively simple code:
Just a trivial call to drawPie().
void drawTrafficPie(void) {
char fileName[NAME_MAX] = "/tmp/ntop-graph-XXXXXX";
TrafficCounter ip;
float p[2];
char *lbl[] = { "IP", "Non IP" };
int num=0;
FILE *fd;
int useFdOpen = 0;
if(myGlobals.device[myGlobals.actualReportDeviceId].ethernetBytes.value == 0) return;
ip.value = myGlobals.device[myGlobals.actualReportDeviceId].ipBytes.value;
p[0] = ip.value*100/myGlobals.device[myGlobals.actualReportDeviceId].ethernetBytes.value; num++;
p[1] = 100-p[0];
if(p[1] > 0)
num++;
#ifndef WIN32
/* Unices */
if(myGlobals.newSock < 0)
useFdOpen = 0;
else
useFdOpen = 1;
if(useFdOpen)
fd = fdopen(abs(myGlobals.newSock), "ab");
else
fd = getNewRandomFile(fileName, NAME_MAX); /* leave it inside the mutex */
#else
fd = getNewRandomFile(fileName, NAME_MAX); /* leave it inside the mutex */
#endif
if(num == 1) p[0] = 100; /* just to be safe */
drawPie(400, 250,
fd, /* open file pointer */
num, /* number of slices */
lbl, /* slice labels */
p, 1); /* data array */
fclose(fd);
if(!useFdOpen)
sendGraphFile(fileName, 0);
}
It wouldn't hurt to test the return from getNetRandomFile() -- but that's trivial. Adding if (fd == NULL) return; before the if(num == 1) line.
Unfortunately, libgd doesn't report errors. Some get put out to stderr (which ntop has closed as part of the daemonizing) so they'll only show up if you run from a console w/o the -d parameter.
Is it possible you are running out of disk space on the /tmp directory??
-----Burton
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Mazuhelli
Sent: Wednesday, August 24, 2005 9:01 AM
To: [email protected]
Subject: Re: [Ntop-dev] A lot of "**WARNING** Error: bad magicnumber[expected=1968/real=0][deviceId=0]" messages...
Hi,
After running for 39.5 hours, ntop crashed again with no error message in the logs. The last messages of the log are:
Aug 23 16:45:48 gbp ntop[2758]: [MSGID0825709] IDLE_PURGE: Device 0 [eth1] FINISHED selection, 1570 [out of 11160] hosts selected
Aug 23 16:45:48 gbp ntop[2758]: [MSGID8477291] IDLE_PURGE: Device 0 [eth1]: 1570/11159 hosts deleted, elapsed time is 0.057194 seconds (0.000036 per host)
Aug 23 16:46:21 gbp ntop[2758]: [MSGID8757584] SFP: Ending fingerprint scan cycle 759 - checked 247, resolved 0
Aug 23 16:47:19 gbp ntop[2758]: [MSGID8931710] RRD: Cycle 381 ended, 61 RRDs updated
Aug 23 16:47:48 gbp ntop[2758]: [MSGID0825709] IDLE_PURGE: Device 0 [eth1] FINISHED selection, 1541 [out of 11219] hosts selected
Aug 23 16:47:48 gbp ntop[2758]: [MSGID8477291] IDLE_PURGE: Device 0 [eth1]: 1541/11218 hosts deleted, elapsed time is 0.051614 seconds (0.000033 per host)
Aug 23 16:48:51 gbp ntop[2758]: [MSGID8757584] SFP: Ending fingerprint scan cycle 760 - checked 245, resolved 0
Gdb gives the following info:
(gdb) info stack
#0 0xffffe002 in ?? ()
#1 0x42095eee in localtime_r () from /lib/tls/libc.so.6
#2 0x400e9b3b in traceEvent (eventTraceLevel=1, file=0x40087b3d "http.c", line=1741,
format=0x4008b080 "http generation failed, alarm() tripped. Please report this to ntop-dev list!") at util.c:2529
#3 0x400404fb in quitNow (signo=14) at http.c:1741
#4 <signal handler called>
#5 0xffffe002 in ?? ()
#6 0x42095eee in localtime_r () from /lib/tls/libc.so.6
#7 0x4003fc72 in sendHTTPHeader (mimeType=4, headerFlags=0, useCompressionIfAvailable=1) at http.c:1431
#8 0x40042b0d in returnHTTPPage (pageName=0x4497b479 "ipTrafficPie.png", postLen=-1, from=0x4497b698,
httpRequestedAt=0x4497af20, usedFork=0x4497af14,
agent=0x4497b338 "Mozilla/5.0 (Macintosh; U; PPC Mac OS X; fr-fr) AppleWebKit/312.1 (KHTML, like Gecko) Safari/312",
referer=0x4497b238 "http://gbp.sti.usherbrooke.ca:3000/", requestedLanguage=0x4497b128, numLang=0, isPostMethod=0)
at http.c:2651
#9 0x40044977 in handleHTTPrequest (from=
{hostFamily = 2, addr = {_hostIp4Address = {s_addr = 2228357892}, _hostIp6Address = {in6_u = {u6_addr8 = "[EMAIL PROTECTED]", u6_addr16 = {2820, 34002, 148, 0, 42368, 16385, 23632, 16896}, u6_addr32 = {2228357892, 148, 1073849728, 1107319888}}}}}) at http.c:3578
#10 0x4007e4be in handleSingleWebConnection (fdmask=0x4497b6ac) at webInterface.c:9038
#11 0x4007e26c in handleWebConnections (notUsed=0x0) at webInterface.c:8890
#12 0x4181a484 in start_thread () from /lib/tls/libpthread.so.0
(gdb) info thread
1 Thread 1150794544 (LWP 12319) 0xffffe002 in ?? ()
Thread 1150794544 (the only one remaining) is again a web server thread, which corresponds to the fact that the source file mentioned is http.c. The line numbers are the same as last time: http.c lines 1741, 1431 and 3578 and webInterface.c lines 9038 and 8890. Last time there were 2 identical ntop processes; this time there is only one.
Would using any of the new MEMORY_DEBUG settings help?
Do you have any other suggestion to try to find out what’s wrong?
I will update to the latest CVS and try again.
Regards,
Marc.
--
Marc Mazuhelli, analyste en sécurité informatique
Service des technologies de l'information, Université de Sherbrooke
Adresses de courriel:
[EMAIL PROTECTED] pour signaler des incidents
de sécurité informatique (virus, intrusions, etc.)
[EMAIL PROTECTED] pour m'écrire directement
téléphone: 819-821-8000, poste 1019
télécopieur: 819-821-8045
_______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
