Documentation Error: https://help.ubuntu.com/lts/serverguide/NTP.html

Bug #1643083 reported by mnieman
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Ubuntu Server Guide
New
Undecided
Unassigned

Bug Description

16.04 Server Documentation Error:

https://help.ubuntu.com/lts/serverguide/NTP.html

Section Timesyncd
"If NTP is installed and replaces the activity of timedatectl the line "NTP synchronized" is set to yes"

$ timedatectl status
      Local time: Fri 2016-11-18 15:46:57 MST
  Universal time: Fri 2016-11-18 22:46:57 UTC
        RTC time: Fri 2016-11-18 22:46:57
       Time zone: America/Denver (MST, -0700)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

"NTP synchronized: yes" this is without NTP and ntpdate removed in order to force timedatectl to take over. "NTP synchronized" has always indicated no with ntpdate installed OR ntp installed

Revision history for this message
Mikkel Kirkgaard Nielsen (mikini) wrote :
Download full text (3.2 KiB)

Whether the systemd timesyncd service is actually running or is bailing out because of other installed ntp clients can be verified by restarting it and then requesting its status from systemctl (restart because I experience that the "start condition" message is not visible in status after some minutes). If it bailed the Condition field will contain a "was not met" message like below indicating the failed condition (here ntpd is installed);

$ sudo systemctl restart systemd-timesyncd.service
$ sudo systemctl status systemd-timesyncd.service
● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: inactive (dead) since Tue 2017-06-06 23:17:14 UTC; 9min ago
Condition: start condition failed at Tue 2017-06-06 23:27:12 UTC; 1s ago
           ConditionFileIsExecutable=!/usr/sbin/ntpd was not met
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 27397 (code=exited, status=0/SUCCESS)
   Status: "Idle."

Jun 06 22:48:15 gc-cust01 systemd[1]: Starting Network Time Synchronization...
Jun 06 22:48:15 gc-cust01 systemd[1]: Started Network Time Synchronization.
Jun 06 22:48:15 gc-cust01 systemd-timesyncd[27397]: Synchronized to time server 10.30.10.100:123 (g
Jun 06 23:17:14 gc-cust01 systemd[1]: Stopping Network Time Synchronization...
Jun 06 23:17:14 gc-cust01 systemd[1]: Stopped Network Time Synchronization.
Jun 06 23:27:12 gc-cust01 systemd[1]: Stopped Network Time Synchronization.

Toggling the boolean of timedatectl set-ntp will disable/enable the timesyncd service as indicated in the "Loaded" status line and in the "Network time on" status of timedatectl (though, the service is still inactive due to the conditions not being met).

Experimenting with all these toggles I however cannot see that anything ever affects the "NTP synchronized" status from timedatectl.

A quick look at the source of timedatectl/d (https://github.com/systemd/systemd/blob/master/src/timedate/timedated.c#L351) indicates that the field's content is the result of a call to adjtimex() and a check of whether the STA_UNSYNC bit in the status field of the resulting structure is set (https://github.com/systemd/systemd/blob/master/src/basic/time-util.c#L1144).

According to the man page this bit means;

"The buf.status field is a bit mask that is used to set and/or retrieve status bits associated with the NTP implementation.

       STA_UNSYNC
              Clock unsynchronized (read-write)."

As I understand this syscall it is only about the kernel's internal adjustment algorithm *given a known discrepancy* obtained from whatever source is available. Looking into kernel code (http://elixir.free-electrons.com/linux/v4.11.3/source/kernel/time/ntp.c) I can't say I understand what's going on but the STA_UNSYNC bit seems be an indication of whether the system thinks that its time is sufficiently close to the correct time (there's something about a maxerror of 500ms). But still it seems to be way more about generic timekeeping than whether time has been retrieved using the ...

Read more...

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.