Ubuntu
ntp package

  1. Bug #1593907
  2. Comment #15

Comment 15 for bug 1593907

Revision history for this message
Christian Ehrhardt  (paelzer) wrote : Re: ntpdate startup routine prevents ntp service from launching up on Ubuntu 16.04 server on system boot; manually starting ntp service works: [FIX in DESCRIPTION], just need to apply it and release a new version

As discussed on IRC:
- the default of -g is also going along with a default of jumping any time >a threshhold ONCE.
  -x can change that

To be sure I tested that on Xenial:
$ timedatectl
      Local time: Thu 2017-06-29 15:58:29 UTC
  Universal time: Thu 2017-06-29 15:58:29 UTC
        RTC time: Thu 2017-06-29 15:58:29
       Time zone: Etc/UTC (UTC, +0000)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

ubuntu@x-ntp-skip-test:~$ sudo timedatectl set-ntp false
ubuntu@x-ntp-skip-test:~$ sudo timedatectl set-time 01:02:03
ubuntu@x-ntp-skip-test:~$ timedatectl
      Local time: Thu 2017-06-29 01:02:05 UTC
  Universal time: Thu 2017-06-29 01:02:05 UTC
        RTC time: Thu 2017-06-29 01:02:05
       Time zone: Etc/UTC (UTC, +0000)
 Network time on: no
NTP synchronized: no
 RTC in local TZ: no

$ sudo add-apt-repository ppa:ci-train-ppa-service/2828
[...]
$ sudo apt install ntp
[...]
$ systemctl status ntp
● ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp; bad; vendor preset: enabled)
   Active: active (running) since Thu 2017-06-29 01:04:36 UTC; 14h ago
[...]
$ timedatectl
      Local time: Thu 2017-06-29 16:02:50 UTC
  Universal time: Thu 2017-06-29 16:02:50 UTC
        RTC time: Thu 2017-06-29 01:05:33

Watch the time the service was started and the time it has now.
It it did warp once initially as it is intended.

If I skew the time later it will not instant-reset again.

Then I dropped the -g from the options to be sure it is this what makes it work and it did not time warp anymore as expected - the offset is known but not solved.
$ ntpq -p
     remote refid st t when poll reach delay offset jitter
==============================================================================
[...]
 golf.zq1.de 192.53.103.103 2 u 51 64 1 13.436 5456358 5456358
And afterwards the service goes active (exited) as according to the -g doc the daemon gives up without -g on too big time deltas.

That said I summarize - good to go on sponsoring trusty and with the SRUs in that regard.