/etc/init.d/ntp doesnt use ntpdate to ensure clocks are aligned before starting server.

Bug #288905 reported by cwsupport
10
Affects Status Importance Assigned to Milestone
ntp (Ubuntu)
Won't Fix
Wishlist
Unassigned

Bug Description

Binary package hint: ntp

Ubuntu: 8.04.1
ntp: 1:4.2.4p4+dfsg-3ubuntu2

Despite other comments on here that ntpdate should be run from ifup scripts there is still a fundamental issue.

If due to failures such as #114505 not bringing up ntpd correctly if the clock drifts you have to ifdown, ifup an interface. On a major server thats just plain ridiculous...To fix the ntp daemon I have to pull down an ENTIRE network interface and stuff every service that is running on that interface - simply to fix ntpd.

The alternative is that I have to either recognise and issue and then

/etc/int.d/ntp stop
ntpdate-debian
/etc/init.d/ntp start

again silly - because an /etc/init.d/ntp restart should work - the point of running NTP is it syncs.

Therefore I propose that the /etc/init.d/ntp script is patched to include running of 'ntpdate-debian' during startup of the ntp server. This is a far more fail-safe method of working instead of forcing the admin to have to remember to run ntpdate-debian in case the clock has drifted excessively.

Tags: patch
Revision history for this message
cwsupport (netsupport) wrote :

The patch I use is:

--- ntp 2008-10-24 22:11:49.000000000 +0100
+++ ntp 2008-10-24 21:34:00.000000000 +0100
@@ -37,6 +37,7 @@
                        log_failure_msg "user \"$RUNASUSER\" does not exist"
                        exit 1
                fi
+ ntpdate-debian
                start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --startas $DAEMON -- -p $PIDFILE -u $UGID $NTPD_OPTS
                log_end_msg $?
                ;;

Revision history for this message
cwsupport (netsupport) wrote :

This patch improves on the last and also sets the hwclock if ntpdate-debian was successful.

Revision history for this message
RichardNeill (ubuntu-richardneill) wrote :

On a system with 3 network interfaces, I see that NTP gets started 5 times and stopped 4 times as the system boots.
This is crazy!

Revision history for this message
Chuck Short (zulcss) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Karmic Koala. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/. Thanks again and we appreciate your help.

Changed in ntp (Ubuntu):
importance: Undecided → Wishlist
status: New → Incomplete
Chuck Short (zulcss)
Changed in ntp (Ubuntu):
status: Incomplete → Triaged
status: Triaged → Confirmed
C de-Avillez (hggdh2)
tags: added: patch
Revision history for this message
Paul Szabo (psz-maths) wrote :

The way I read "man ntpd" (on Debian wheezy), we could (should?) replace ntpdate by
"ntpd -q"; and if we are going to run ntpd then ntpdate is unnecessary anyway.
If we have (or are going to have) ntpd, then we should simply skip /etc/network/if-up.d/ntpdate;
seeing how that depends on NTPSERVERS in /etc/ntp.conf or somesuch, I do not see that
/etc/network/if-up.d/ntpdate is ever any use.

Revision history for this message
Cam Cope (ccope) wrote :

It can be dangerous to step the clock while applications are running (see the fallout from the last couple of leap seconds). Stepping only needs to be done at boot. It makes more sense to just have separate init scripts for both ntpdate and ntp and to order them correctly. Adding ntpdate to the ntp init script would make it impossible to make changes to your ntpd configuration without stepping the clock (again, dangerous) or rebootinng.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi, this long dormant bug has been resurrected early last year, but I think it is time to close it.

There were various discussions in the bug about when to set or drift, but while all is correct that isn't the scope of the bug.
There are other open that will address e.g. that on a running system you shouldn't time warp but instead drift, just as comment 6 explains. And I agree - other than explicitly requested - in a systems lifetime time should only drift, but not be reset.

But then the request here was about setting time correctly initially (set) and kept correct later (drift).
That is now done by systemd anyway - see timedatectl for a starter if you are interested.
That said the bug no more really "applies", due to that.
So it is not fix released but Won't Fix (Alt solution available and being the default)

Changed in ntp (Ubuntu):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.