Project

General

Profile

Bug #6053

remove ntpdate_sync_once.sh, ntpd -g suffices

Added by Dmitriy K over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Normal
Category:
NTPD
Target version:
Start date:
04/01/2016
Due date:
% Done:

0%

Estimated time:
Affected Version:
2.3
Affected Architecture:
All

Description

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.

Associated revisions

Revision 5a758355 (diff)
Added by Renato Botelho over 3 years ago

Ticket #6053

- Do not call ntpdate before start ntpd, ntpd g parameter is enough
Deprecate /usr/local/sbin/ntpdate_sync_once.sh
- Remove system_ntp_configure parameter and always start ntpd

Revision 2dced82f (diff)
Added by Renato Botelho over 3 years ago

Ticket #6053

- Do not call ntpdate before start ntpd, ntpd g parameter is enough
Deprecate /usr/local/sbin/ntpdate_sync_once.sh
- Remove system_ntp_configure parameter and always start ntpd

(cherry picked from commit 5a758355ec9a20ff75c9191b6915df64255fb8be)

History

#1 Updated by Jim Thompson over 3 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):
[...]
system_ntp_configure(false);
mwexec_bg("/usr/local/sbin/ntpdate_sync_once.sh", true);
echo "done.\n";
[...]
/* lock down console if necessary */
reload_ttys();

/* load graphing functions */
enable_rrd_graphing();

/* enable watchdog if supported */
enable_watchdog();
[...]

Where /usr/local/sbin/ntpdate_sync_once.sh 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.

See: http://doc.ntp.org/4.1.1/ntpdate.htm

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: http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate

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 server1.name.net server2.name.org server3.name.com

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

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

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.

See: http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate#Set_the_time_before_running_ntpd

#2 Updated by Renato Botelho over 3 years ago

Dmitriy,

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

#3 Updated by Renato Botelho over 3 years ago

  • Status changed from New to Feedback

#4 Updated by Chris Buechler over 3 years ago

  • Subject changed from rc.bootup spams on boot to remove ntpdate_sync_once.sh, 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