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? -- View this message in context: http://rrd-mailinglists.937164.n2.nabble.com/recover-from-logged-incorrect-time-tp1073160p7314578.html Sent from the RRDtool Users Mailinglist mailing list archive at Nabble.com. _______________________________________________ rrd-users mailing list [email protected] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
