Hi all this problem is funny. In fact I can't see how the updateASTraffic() function can crash ntop. Instead RRDs always need to go 'forward' so if NTP decides that your box time needs to go backwards, some RRD updates will fail for some time.
Can you tell me again/precisely how to crash ntop with time shifting? Thanks Luca On Feb 5, 2009, at 3:12 AM, Rob Shupe wrote: > Thanks, will do. A few questions though-- I didn't make any major time > changes on the server, but it *is* set to stay sync'd to an NTP > server. > If that synchronization adjusts the time even slightly (maybe a second > or two), will it still cause this problem? In other words, can I run > nTop on a server that is staying sync'd via NTP, or will I have to > turn > NTP off to prevent this problem? Additionally, will this problem > always > occur with changes like daylight saving time? What if I need to adjust > the time for some reason, can I just stop nTop, adjust time and > restart, > or will the problem still occur? Sorry for all the questions, just > trying to understand how this works better to prevent the problem > going > forward. Thanks again for your help! > > Walt Henley wrote: >> If you change the time on the box, this happens. Delete your RRD >> directory under /usr/ntop/lib and the dtatbases in the lib directory >> and try again. >> >> On 2/4/09, Rob Shupe <[email protected]> wrote: >> >>> (note—I'm sending this again from a different address, my other >>> one doesn't >>> seem to get through. Apologies if this double-posts somehow) >>> >>> >>> >>> I've been running nTop 3.3.9 on a CentOS 5 box, and it ran quite >>> well for >>> about a week or two. However, now when I start it up, it'll run >>> for a few >>> minutes and then segfault and die. I ran nTop using the gdb >>> debugger, and >>> this was the output it gave at the time of the segfault: >>> >>> >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> >>> [Switching to Thread -1314034800 (LWP 28839)] >>> >>> updateASTraffic (actualDeviceId=0, src_as_id=0, dst_as_id=27357, >>> octets=297) >>> >>> at pbuf.c:1011 >>> >>> 1011 if(stats->as_id == src_as_id) { >>> >>> >>> >>> Does anyone have any ideas about what is happening based on this >>> output? If >>> additional information is needed, please let me know and I'll be >>> happy to >>> send it along. Thanks. >>> >>> >>> >>> -Rob >>> >>> >> >> > > _______________________________________________ > Ntop mailing list > [email protected] > http://listgateway.unipi.it/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
