Now that's a fine and useless report, Ollie. No Stan, it's another fine mess YOU'VE gotten US into again.
When you say +CVS do you mean the development version (3.0.050) or the actual 3.0 release (3.0)?? Differences - today - are small, but that's not always true. What trace level? If you aren't at 4+, there aren't a lot of messages generated from the routine tasks like purge. At 4 there should be a steady pitter patter. 5 and 6 don't add much, just change the format of the messages. Basically, the only way is to run under gdb (instructions are in docs/FAQ), however, there is an observer effect - where gdb changes some of the handling of POSIX threads, so some problems never reoccur under gdb... There are some indirect things to try: 1) There's a large # of debug switches in globals-defines.h at 371ff, but without a clue, it's hard to know which to turn on - and some of them will generate a lot of output. 2) There are code options to enable backtraces ... turning them on MIGHT give you info, but it will be in hex offsets and so unique to your compile. The main one is controlled by config.h: #define HAVE_BACKTRACE 1 automatically IF you have the right version of gcc. If it's dying on web requests, there's another trap for the reporting child, look in globals-defines.h: /* * This flag turns on a signal trap in webInterface.c and in http.c for * the children. If you're seeing pages simply and silently die, this * might catch the signal and log it for analysis. */ /* #define MAKE_WITH_HTTPSIGTRAP */ There is also MAKE_WITH_RRDSIGTRAP and MAKE_WITH_NETFLOWSIGTRAP if you are using those plugins. All of these will - unfortunately - generate a backtrace in hex. That is file+offset, which is meaningless without your precise compile. A trick that might work. gdb /usr/bin/ntop <-- load the program set args xxxxxx <--- normal parameters minus -L --use-syslog and -d --daemon run Wait a few seconds, until ntop gets going - maybe until you see the sniffying message, then press control + c That should get you to a break point with ntop loaded. You can then do list commands to convert the offsets into a line... You will have to look at the gdb help for the precise syntax, it's like list *address. -----Burton > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf > Of [EMAIL PROTECTED] > Sent: Wednesday, April 07, 2004 9:02 AM > To: [EMAIL PROTECTED] > Subject: [Ntop-dev] ntop 3.0+CVS unstable with large traffic > > > We are trying to use Ntop to monitor our network running as daemon mode. > > After a period of about 2-3 days, ntop will just die the logs > don't show anything interesting nor do I see any coredumps. How > can I properly debug ntop so I can determine why its dying? > > Thanks > > Shawn. > > _______________________________________________ > Ntop-dev mailing list > [EMAIL PROTECTED] > http://listgateway.unipi.it/mailman/listinfo/ntop-dev _______________________________________________ Ntop-dev mailing list [EMAIL PROTECTED] http://listgateway.unipi.it/mailman/listinfo/ntop-dev
