Several insights on all of this:

"who wins":
install ntp, chrony or openntp (can only be one so take chrony) - reboot - who 
wins?
-> Seems to work always to be chrony, but why.
-> also matches some tests by waveform
I started a discussion with systemd upstream if there are guarantees.
On IRC it was suggested that it might just be alphanumeric.
I made some tests to check the influence of other things like enabling in 
different orders.
But it stuck to alphanumeric wins.
In our case that is great as every NTP service name is >> systemd-timesyncd.
While opening a systemd github issue to be sure I found that it is actually 
random.
And it seems there is no way ton control it.
Until that exists we can re-arrange our POV:
- this is only a "problem between systemd-timesyncd and the servers"
- the old condition to not start when installed would avoid that completely
- a perfect solution (that detects not "installed" but running) could wait 
until upstream solves it


"masking":
I found that the "Masking" of chrony/ntp services is actually a conflicts in 
packaging- that is good (because it is the right thing to do).
That means that one who installs one of the NTP servers is removing the others 
(that is just right so). The packages solve that via a virtual package to not 
have to list all of each other.
openntp and chrony and ntpsec provide "time-daemon"
They all conflict with time-daemon, so only one of them can be installed even 
not listing all of them.
The only outlier is ntp (did I mentione we went away from it), but for that all 
of them explicitly conflict with ntp as well.

"Severity" -> low/med:
Of the above of case 1-3 were worse on Xenial
Xenial => systemd-timesyncd
Xenial - install ntpd => ntpd AND systemd-timesyncd running
Xenial - then after reboot, only ntpd
This is due to ntp being a sysV script in Xenial and has no way to express the 
conflicts.
Due to that both run, only after a reboot the condition in the old 
systemd-timesyncd would prevent it from starting.
But it would even have done so if ntp was only installed, but not running.
And while broken we never had bugs about the above in the last two years.
And the conflicts behavior is better than that at least.


Summarizing what we really need now:
1. better completeness of those services conflicting with each other (simple 
add to their .service files) - one "direction" of conflicts is enough so fix 
those in main (chrony in that case)
2. determinism (which starts if multiple are installed)
   For now re-vive what 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873185 dropped
3. after removal of the NTP daemons we'd want systemd-timesyncd to pick up 
again immediately (without a reboot)


** Bug watch added: github.com/systemd/systemd/issues #8730
   https://github.com/systemd/systemd/issues/8730

** Also affects: systemd via
   https://github.com/systemd/systemd/issues/8730
   Importance: Unknown
       Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1764357

Title:
  start/stop of conflicting time services not well coordinated

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1764357/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to