I also had some "apparent" increased stability when using -K. I set this arg to help in the debugging and then the darn thing wouldn't crash anymore! I didn't have stringent control processes so I'm sure I made other changes, but I haven't had a chance to prove/disprove if -K truly helps stabilize anything.
G -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ian McDonald Sent: Tuesday, August 26, 2008 12:26 PM To: [email protected] Subject: Re: [Ntop] ntop dying with SegFault at line 26 I can re-create this crash fairly much at will. Deleting the dnscachedb does fix it, until it recurs some time after. I have a box with a reasonable traffic load, and it segV's within a few minutes of starting up after the first crash. Until the first crash, it runs pretty well for a day or so. This is ntop svn, checked out yesterday, compiled on Debian 4.0. Here's a backtrace of the crash from "ntop -t 6 -c -x 65536 -i eth0" The debuggler is still attached, if anyone wants me to execute commands. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1354769488 (LWP 24789)] 0xb755d500 in _gdbm_get_bucket () from /usr/lib/libgdbm.so.3 (gdb) bt #0 0xb755d500 in _gdbm_get_bucket () from /usr/lib/libgdbm.so.3 #1 0xb755db79 in _gdbm_alloc () from /usr/lib/libgdbm.so.3 #2 0xb755bec5 in gdbm_store () from /usr/lib/libgdbm.so.3 #3 0xb78b29f7 in ntop_gdbm_store (g=0x80f1488, d= {dptr = 0xaf3fa980 "1255987146", dsize = 11}, v= {dptr = 0xaf3fa9e0 "www.ontariohockeyacademy.com", dsize = 72}, r=1, theFile=0xb79093d2 "protocols.c", theLine=659) at leaks.c:835 #4 0xb78cd9af in processDNSPacket (srcHost=0x8a344b0, sport=53, packetData=0xaf3fb10e "\216\217\204", length=<value optimized out>, isRequest=0xaf3fac40, positiveReply=0xaf3fac3e) at protocols.c:659 #5 0xb78bf173 in processIpPkt (bp=0xaf3fb0f2 "E", h=0xaf3fd14c, length=198, ether_src=0xaf3fb044 "", ether_dst=0xaf3fb03e "", actualDeviceId=0, vlanId=65535) at pbuf.c:1754 #6 0xb78c44a3 in processPacket (_deviceId=0x0, h=0xaf3fd14c, p=<value optimized out>) at pbuf.c:3686 #7 0xb78c903d in queuePacket (_deviceId=0x0, h=0xaf3fd14c, p=0x80cbad0 "") at pbuf.c:2505 #8 0xb78ed3df in pcap_read_packet (handle=0x80cb8a8, callback=0xb78c8d80 <queuePacket>, userdata=0x0) at ./pcap-linux.c:802 #9 0xb78ecee6 in pcap_read_linux (handle=0x80cb8a8, max_packets=-1, callback=0xb78c8d80 <queuePacket>, user=0x0) at ./pcap-linux.c:469 #10 0xb78ef134 in pcap_dispatch (p=0x80cb8a8, cnt=-1, callback=0xb78c8d80 <queuePacket>, user=0x0) at ./pcap.c:77 ---Type <return> to continue, or q <return> to quit--- #11 0xb78b68cc in pcapDispatch (_i=0x0) at ntop.c:94 #12 0xb7884240 in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #13 0xb77eb49e in clone () from /lib/tls/i686/cmov/libc.so.6 -- ian Kevin Freels wrote: > Sorry, forgot to update. > > I deleted the db files and made sure it was running with debug ("-t 6"), > and it hasn't crashed in a week. > > Go figure. > > I'll leave it like this until the next problem happens. Thanks for the > help!!!! > > ....k > -=-=-=- > >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Gary Gatten >> Sent: Friday, August 15, 2008 11:17 AM >> To: [email protected] >> Subject: Re: [Ntop] ntop dying with SegFault at line 26 >> >> Just for kicks delete the db files - especially the dnscache. >> Let us know if that helps - maybe rename the old ones and >> save them for analysis if need be! >> >> Gary >> >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On >> Behalf Of Kevin Freels >> Sent: Friday, August 15, 2008 12:53 PM >> To: [email protected] >> Subject: Re: [Ntop] ntop dying with SegFault at line 26 >> >> Greetings! >> >> The crashes are starting to happen again. It ran fine for a >> few weeks, and then suddenly started dying about three weeks >> ago. Nothing has been changed on the system it's running on >> (FC7). Here's the flags for the command line: >> >> NTOPCfg=" -w 3001 -i eth0,eth1 -M -K -z -t 6 -x 4096" >> >> Attached is the stdout from the start up until the crash, it >> ran about 50 minutes. >> >> ....k >> -=-=-=- >> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >> On Behalf >>> Of Kevin Freels >>> Sent: Monday, June 02, 2008 1:42 PM >>> To: [email protected] >>> Subject: Re: [Ntop] ntop dying with SegFault at line 26 >>> >>> Luca, >>> >>> I have started ntop with the CLI you prescribed. Here is >> the history >>> of the commands I had set up in the init.d script (commented-out >>> configs are ones I tried in succession): >>> >>> NTOPBin=/usr/local/bin/ntop >>> #NTOPCfg=" -w 3001 -i eth0,eth1 -M -c -d -t 5" >>> #NTOPCfg=" -w 3001 -i eth0,eth1 -M -c -t 5" >>> #NTOPCfg=" -w 3001 -i eth0 -c -t 5" >>> #NTOPCfg=" -w 3001 -i eth0 -c -t 5 -x 4096" >>> #NTOPCfg=" -w 3001 -i eth0,eth1 -M -z -t 5 -x 4096" >>> NTOPCfg=" -w 3001 -i eth0,eth1 -M -K -z -t 6 -x 4096" >>> >>> Over this last weekend, I limited the hosts hash and --sticky-hosts >>> with "-x 4096" and dropped the "-c". It ran all weekend >> long until the >>> disk filled up (but not from ntop, another issue). So perhaps the >>> --sticky-hosts and the host hash limits are the trick....? In any >>> event, it seems to be working now. >>> >>> I'll keep an eye on it for the week (or until it crashes). >> If it keeps >>> going, maybe I'll fool around with the host hash limit, >> incrementally >>> raising it. If anything happens to cause it to die, I'll forward on >>> the gruesome details. >>> >>> Thanks for the reply!!! >>> >>> ....k >>> -=-=-=- >>> >>>> -----Original Message----- >>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >>> On Behalf >>>> Of Luca Deri >>>> Sent: Sunday, June 01, 2008 12:30 AM >>>> To: [email protected] >>>> Subject: Re: [Ntop] ntop dying with SegFault at line 26 >>>> >>>> Kevin >>>> in what setup are you running ntop? WAN perhaps? What is >>> the exact CLI >>>> command you're using? Can you please start it from shell >>> and add -K -t >>>> 6 and send the log. >>>> >>>> Thanks Luca >>> _______________________________________________ >>> Ntop mailing list >>> [email protected] >>> http://listgateway.unipi.it/mailman/listinfo/ntop >>> >> >> >> >> >> <font size="1"> >> <div style='border:none;border-bottom:double windowtext >> 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is >> intended to be reviewed by only the intended recipient and >> may contain information that is privileged and/or confidential. >> If you are not the intended recipient, you are hereby >> notified that any review, use, dissemination, disclosure or >> copying of this email and its attachments, if any, is >> strictly prohibited. If you have received this email in >> error, please immediately notify the sender by return email >> and delete this email from your system." >> </font> >> >> _______________________________________________ >> Ntop mailing list >> [email protected] >> http://listgateway.unipi.it/mailman/listinfo/ntop >> > _______________________________________________ > Ntop mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop > > _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop <font size="1"> <div style='border:none;border-bottom:double windowtext 2.25pt;padding:0in 0in 1.0pt 0in'> </div> "This email is intended to be reviewed by only the intended recipient and may contain information that is privileged and/or confidential. If you are not the intended recipient, you are hereby notified that any review, use, dissemination, disclosure or copying of this email and its attachments, if any, is strictly prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system." </font> _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
