On 07.04.15 at 16:40, Lennart Poettering wrote: > On Sun, 05.04.15 13:25, Jakub Klinkovský (j....@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ý
pgpOtJz1HDTh2.pgp
Description: PGP signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
