Bug #6053


remove, ntpd -g suffices

Added by Dmitriy K about 8 years ago. Updated about 8 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
Affected Architecture:


rc.bootup: The command '/usr/bin/nice -n20 /usr/local/bin/rrdtool update /var/db/rrd/lan-traffic.rrd N:U:U:U:U:U:U:U:U' returned exit code '1', the output was 'ERROR: /var/db/rrd/lan-traffic.rrd: illegal >attempt to update using time 1459499576 when last update time is 1459509340 (minimum one second step)

A block of 10 consecutive msgs. This block sometimes repeats again.

Clean install x64. Nothing is configured yet.

Actions #1

Updated by Jim Thompson about 8 years ago

  • Category set to NTPD
  • Assignee set to Renato Botelho

Difference between timestamps is -9764. Assuming that's seconds, nearly 3 hours. Is it possible that NTP has come up and set the clock back?

rc.bootup says (in part):
mwexec_bg("/usr/local/sbin/", true);
echo "done.\n";
/* lock down console if necessary */

/* load graphing functions */

/* enable watchdog if supported */

Where /usr/local/sbin/ loops up to 3 times attempting to get non-zero status out of:
/usr/local/sbin/ntpdate -s -t 5 ${SERVER}

Since the ntpd default is to slew the clock, unless the offset is greater than +- 128ms, in which case the clock is stepped using settimeofday(),
it could be that RRD is starting in the middle of a large offset, brought on by ntpd running, or even (I've not thought this through), that the offset so large (backwards), that it's before the previous invocation of RRD stopped recording.


Note that this file recommends the use of '-b' switch for ntpdate in startup scripts, which always steps the clock. (We don't do this.)

Note as well that ntpdate is deprecated:

The new shiny is 'ntpd -g' "allow the first adjustment to be Big", and, in fact, ntpdate can be all but replaced with:'
ntpd -gqc /dev/null

But, really, the whole mwexec_bg("/usr/local/sbin/", true); crap should be eliminated, we already run:

/usr/local/sbin/ntpd -g -c /var/etc/ntpd.conf -p /var/run/

Which should be good enough, except for the initial offset problem.

At a minimum, we should probably change the usage of ntpdate to be:

sntp -sS ${SERVER}

Note that '-t 5' is implied here.

But, at the end of the day, It is no longer necessary to set the time before starting ntpd. Using the -g option to ntpd means the system will need to have the time set to within 68 years (more or less) before starting ntpd.


Actions #2

Updated by Renato Botelho about 8 years ago


The only possible cause for the rrdtool message you mentioned is the machine clock was set to the future and then set to current time again. And in this meantime rrdtool was updated using the future time. Since the difference is ~3h, you will stop to see this message after 3 hours but as a side-effect your graphs will have no information to this 3h window.

This is how rrdtool works and there is nothing we can do about it unless try to make the best to start ntpd on boot and keep box clock accurate

Actions #3

Updated by Renato Botelho about 8 years ago

  • Status changed from New to Feedback
Actions #4

Updated by Chris Buechler about 8 years ago

  • Subject changed from rc.bootup spams on boot to remove, ntpd -g suffices
  • Status changed from Feedback to Resolved

updated subject to issue that was fixed here.

OP's issue is the time was 3 hours into the future at some point, and after correcting via NTP, there was a period where it wouldn't add more data.


Also available in: Atom PDF