Added the related Debian bug I opened.
Also renamed as (for now) here we only address #3 of the issues described.
If conclusion with Debian and/or Upstream is reached we can use that as well.
But with the remaining uncertainty (and all real tests being good) we won't
change anything for #2 yet.
#2 here some theory by smoser (thanks)
http://paste.ubuntu.com/p/6JDQ9ycJhw/
I tested on that and it works reliable.
TL;DR as long as we have ONE base service "=conflictee" and ONE extra service
"=conflicter".
then systemd will always run the second.
Fortunately in Debian/Ubuntu the apt level
#1 is solved by the package conflicts
#2 might be solved by very suble wording in systemd
#3 might be low prio as it was never different
Going on to check #2 atm
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Linked the upstream discussion on the determinism of conflicting
services.
--
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
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
Status right now:
ok - 0. systemd-timesyncd
ok - 1. default install - install chrony => Chrony
fail - 1b. - remove chrony => none (ok after reboot)
ok - 2. default install - install ntp => NTP
fail - 2b. - remove ntp => none (ok after reboot)
ok - 3. default install - install openntp =>
Lets break this into use cases in Bionic:
I was not sure who should win in each case.
We might either want the clear "order" chrony > ntp > openntp >
systemd-timesyncd
Or we might want a "last installed" approach, but that is hard as upgrades to
not count here only real "install". What would
