Gotcha... the debug is via #define so it doesn't increase code size - a big part of each debug message is the format line...
Keep an eye on directory permissions. If you chmoded at some point (I often do this because I run under gdb as root and then those files can't be opened by normal users), sometimes the parent doesn't get modified and so you can't create new files, but can update old ones. I've built recently (although not intentionally) with RRD_DEBUG (the #define had crept into the code) and don't remember any problems other than lots and lots of messages... you might try valgrind (there's actually a valgrind setting in the ntop.init [RedHat/fedora] script in packages/RedHat ... ) -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Porter Sent: Monday, May 30, 2005 6:53 PM To: [email protected] Subject: RE: [Ntop] rrd not updating --On Saturday, May 28, 2005 6:20 AM -0500 Burton Strauss <[EMAIL PROTECTED]> wrote: > Nope, Ken, I really meant debug - as in the #define in the source. Ok, thanks. Most services have a debug command line switch, and the closest thing I saw in ntop was the tracelevel switch. Hence my confusion. The lightbulb came on slowly to tell me to look in the source for a compile-time switch. > I'll bet it's the usual culprit - permissions... debug should show > the error messages, although most errors should have already appeared > in the log. I considered that but the rrd tree is all owned by user ntop. But it's still possible that I'm missing something obvious from staring at it too closely. > I'd focus on rrdPlugin.c first. Nothing in mainline code is going to > matter. The enumeration code - such that it is - is in initDevices(), > but it just calls uses what you give on the -i parameter or calls > pcap_findalldevs. I highly doubt that's got major problems. I got as far as rebuilding with RRD_DEBUG defined and then the new binary was crashing trying to initialize the gdbm stuff. I started investigating with gdb and it looks like stack clobberage (EBX getting zeroed resulting in a null pointer dereference), maybe a gdbm issue. I had to put this on the shelf at that point but I'll go take another crack at it soon. _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
