[rrd-users] recover from logged incorrect time

Steve Shipway s.shipway at auckland.ac.nz
Fri Feb 24 23:28:00 CET 2012


We run ntp on our RRD/MRTG servers here, since time sync is so important, and I've never had this sort of issue.

Are you sure that you're not getting a time synch issue with NTP rather than with RRDTool?  I don't know where you're ntpsynching from, or your ntpd params - maybe make sure that ntpd is set so it will not change the clock if is seems to be more than 1min out of synch (which would indicate an NTP issue).  A 1-hour error seems as if some server is confusing daylight savings time with the real time... if your servers are simply using ntpd to come to a consensus on time (via broadcast) rather than all synching from a single specified trusted source, a misconfigured server pushing out incorrect times somewhere on your network *might* do this?

Steve

Steve Shipway
University of Auckland ITS
UNIX Systems Design Lead
s.shipway at auckland.ac.nz
Ph: +64 9 373 7599 ext 86487


________________________________________
From: rrd-users-bounces+s.shipway=auckland.ac.nz at lists.oetiker.ch [rrd-users-bounces+s.shipway=auckland.ac.nz at lists.oetiker.ch] on behalf of Otheus [otheus+rrd at gmail.com]
Sent: Saturday, 25 February 2012 12:22 a.m.
To: rrd-users at lists.oetiker.ch
Subject: Re: [rrd-users] recover from logged incorrect time

I have a related problem.

On our server we're running RRDtool 1.4.4

Remote monitoring servers connect to the RRDtool via TCP socket; rrdtool is
configured on the server to run under xinetd in 'remote command' mode.
Everything works fine most of the time.

Once every few days, one or more servers will show that the last-update time
is maybe one hour in the future. I fixed this once using the
dump-edit-restore method. But that's not a solution for the long-run.

The "correct" RRD databases show a timestamp which matches the wall-clock
time according to perl's localtime() function. The incorrect one(s) will
show a timestamp of about +3600 seconds.

Is there a known problem with rrdtool in command mode that would lead to
such clock skews? Could it be that ntp running on both hosts would interfere
with rrdtool?





More information about the rrd-users mailing list