[systemd-devel] Questions about timedatectl and NTP

[Lennart Poettering]

On Sun, 05.04.15 13:25, Jakub Klinkovský (j.l.k at gmx.com) wrote:

> As per systemd 216 NEWS [1], alternative NTP implementations should add
> Conflicts=systemd-timesyncd.service to be recognized by systemd, which
> ntpd.service on Arch Linux does. But still, active ntpd.service does not seem
> to be recognized by timedatectl:

Correct, timedatectl only shows systemd-timesyncd's status now. I have
now updated the man page to clarify this.

> 
> $ timedatectl
> ...
>      NTP enabled: no
> NTP synchronized: yes
> ...
> 
> If I'm reading the code [2] correctly, the 'timedatectl set-ntp' command only
> handles systemd-timesyncd.service and does not take into account any other NTP
> implementations. This is in contrast with timedatectl(1) [3] which explicitly
> shows an example where timedatectl starts chronyd.service.

Indeed, I fixed this now in the man page, too!

> Also, I think that since systemd 216 the "NTP enabled" field in timedatectl's
> output should read "timesyncd enabled" to avoid confusion. Many people still
> have trouble understanding that NTP != ntpd and timedatectl currently adds
> another term to the inequality.

Hmm, I have now renamed this in the man page and the output to
"network time synchronization", to disconnect this a bit from the
low-level technology, and as a side-effect hopefully removing the
confusion with the classic ntp package.

systemd-timesyncd currently does NTP as well as ensuring a monotonic
clock using a flags file. In the future it hopefully will do PTP too,
one day, hence it probably makes sense to use a more generic term than
just NTP to describe it. After all, our daemon is called
"systemd-timesyncd" rather than "systemd-ntpd", precisely to reflect
that it shall not be bound to one specific protocol.

> Finally, I think there is a bug in how the Conflicts= specification is supposed
> to work. Suppose that systemd-timesyncd.service is inactive and some other
> service, specifying Conflicts=systemd-timesyncd.service is active -- let's call
> it ntpd.service as mentioned above. Now, when the user runs
> 'timedatectl set-ntp true' the systemd-timesyncd.service is first enabled and
> then started. Due to the Conflicts= declaration, ntpd.service is stopped, but
> remains enabled. Later on, when the user reboots, ntpd.service will be started
> instead of systemd-timesyncd.service -- this is the behaviour described in
> systemd.unit(5) [4].

Hmm, indeed.

I figure we should add a way to queue a start job that will fail if it
would mean stopping any existing service, and then use this here. That
way timesyncd would not be started if any conflicting NTP service
would already be running, and all should be good. Added this to the
TODO list.

Lennart

-- 
Lennart Poettering, Red Hat