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:
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 */
#endifif(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);
}
Just a trivial call to
drawPie().
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...
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
Computer security analyst
Service des technologies de l'information
Université de Sherbrooke
On 08/22/05 09:06, Marc Mazuhelli wrote :
Hi Burton,
A version with your latest patches was started Friday morning. It ran OK until 3:44 AM this morning and crashed with no error message whatsoever in the logs, like it did twice last week (before updating to the new CVS version):
# ps -axf | grep ntop
1824 pts/1 S 0:00 | \_ grep ntop
16185 ? S 0:00 /usr/local/ntop3cvs/bin/ntop -i eth1 @/etc/ntop3cvs.conf
16186 ? S 0:00 /usr/local/ntop3cvs/bin/ntop -i eth1 @/etc/ntop3cvs.conf
# [EMAIL PROTECTED] ntop]# gdb /usr/local/ntop3cvs/bin/ntop 16185
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
... <snip>
Loaded symbols for /lib/libnss_dns.so.2
0xffffe002 in ?? ()
(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 0x40041a13 in returnHTTPPage (pageName=0x4497b479 "pktSizeDistribPie.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:2662
#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 threads
1 Thread 1150794544 (LWP 16185) 0xffffe002 in ?? ()
(gdb)
Thread 1150794544 corresponds to a web server thread:
Aug 19 08:33:12 gbp ntop[14810]: [MSGID9305063] THREADMGMT[t1150794544]: WEB: Server connection thread running [p14810]
<snip>
_______________________________________________ Ntop-dev mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
