I changed the time on my server and it began to crÀsh. I blew away the entire database and it seemed to run OK after that. Could have been corruption I guess. It was definitely associated with the time change though.
On 2/5/09, Luca Deri <[email protected]> wrote: > 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 > -- Sent from my mobile device _______________________________________________ Ntop mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop
