Does having hyperv-daemons enabled show that the system clock is synchronised by timedatectl?

Question

We are opting to disable chronyd in favour of using hyperv-daemons to keep our server clocks in sync so that the guest OS time is managed by the machine that the VM is running on.

After disabling chronyd and enabling hyperv-daemons, the server clock is not drifitng.

However, when running timedatectl we can see that the output says that the system clock is not being synchronised:

[user@server ~]$ timedatectl
               Local time: Tue 2021-09-07 10:54:08 BST
           Universal time: Tue 2021-09-07 09:54:08 UTC
                 RTC time: Tue 2021-09-07 09:54:08
                Time zone: Europe/London (BST, +0100)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

Does timedatectl set the value of 'System clock synchronized' only by checking if the chronyd service is running?

Why do you want to discard chronyd? – Nils Sep 12 '21 at 21:39 — Nils, Sep 12 '21 at 21:39

score 1 · Answer 1 · answered Sep 10 '21 at 10:56

timedatectl gets the synchronization information from systemd-timedated.service.

Depending on the version of systemd-timedated.service, it may be aware of:

only systemd-timesyncd.service,
a built-in list of synchronization services,
a colon-separated list of services in environment variable SYSTEMD_TIMEDATED_NTP_SERVICES in the environment of the systemd-timedated.service process
and/or a list of services in (/usr/lib)|(/usr/local/lib)|(/etc)/systemd/ntp-units.d/*.list files, one per line.

The NTP service display is basically determined by "Is any of the services listed as NTP synchronization services running or not?"

The System clock synchronized information comes from the kernel: if the kernel knows that a time synchronization service is providing updates to it, the kernel clears the 7th bit in the time_status variable within the kernel. You can view the value of this variable with adjtimex --print: if the 7th bit (value 64) is set in the status value displayed by it, then the system clock is not being synchronized. The timedatectl / systemd-timedated.service uses this bit as the source for its System clock synchronized: yes/no display.

If your version of systemd-timedated.service supports the SYSTEMD_TIMEDATED_NTP_SERVICES environment variable (check the man page of the service), then you could create an override file like this as /etc/systemd/system/systemd-timedated.service.d/override.conf:

[Service]
Environment=SYSTEMD_TIMEDATED_NTP_SERVICES=<name of HyperV daemon .service here>:chronyd.service:ntp.service:systemd-timesyncd.service

Obviously replace <name of HyperV daemon .service here> with the actual name of the .service file of the appropriate HyperV daemon.

After creating this override file and restarting systemd-timedated.service, the timedatectl command should now show NTP service: active if any one of the services listed in the environment variable is running (according to systemd).

If the HyperV daemons don't themselves update the system clock synchronization status bit, you apparently could do it yourself with adjtimex --status 0 to indicate that the clock is synchronized, or adjtimex --status 64 to indicate it's unsynchronized. (Note: I don't claim to fully understand the kernel timekeeping system, so if you choose to do this, it will be at your own risk. There might be a good reason why the HyperV daemons don't update this status bit.)

When you use timedatectl set-ntp true, systemd-timedated will check the services mentioned in its list of time synchronization servers, and will attempt to enable & start the first service it finds installed, so the list in the SYSTEMD_TIMEDATED_NTP_SERVICES should be ordered according to your preference.

Does having hyperv-daemons enabled show that the system clock is synchronised by timedatectl?

1 Answers1