[systemd-devel] Questions about timedatectl and NTP

[Jakub Klinkovský]

On 07.04.15 at 16:40, Lennart Poettering wrote:
> 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.

After looking at the code more thoroughly, I must say that this commit [1] is
not entirely correct and might bring some more confusion. There are two
different states being reported. The (former) "NTP enabled" field refers to, as
you say, only the systemd-timesyncd's status, but the "NTP synchronized" field
is general, glibc's adjtimex is used to report the status [2].

[1]: http://cgit.freedesktop.org/systemd/systemd/commit/?id=ff5921bae27b4f3fedb339a3a32dc527c9b3a88c
[2]: http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/time-util.c#n864

> 
> > 
> > $ 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.

I agree with using "network time synchronization" in the man page, but can we
make it "timesyncd enabled" (or similar) instead of "Network Time on" in the
timedatectl's output? The idea is to refer explicitly to systemd-timesyncd in
order to avoid confusion with every other network time syncing tool, not only
ntpd.

> 
> 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.

-- 
Jakub Klinkovský
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20150407/cc1f7d20/attachment.sig>