Package: systemd
Version: 238-4

in an old
workaround was dropped because all NTP servers now
ship Conflicts=systemd-timesyncd.service but in my tests I found that
systemd in this case is still unreliable.

We end up with a NTP server (chrony, ntp, ...) and systemd-timesyncd both
being enabled and systemd on startup randomly picking one of them.

I filed systemd upstream to
get educated how one could control it or at some time there might be a way
to express this added.

But until then I wonder how we can make any guarantees which service is
OTOH while trivial experiments trigger easily I haven't seen chrony to be
knowcked out by systemd-timesyncd in real-life. Maybe there is a second
safety mechanism I don't know yet?

But if I'm right and this is just as unreliable as it is in my tests I
wonder if we should take the old stop-gap measure back into systemd for now
in Debian and Ubuntu.

Note - LP Bug in ubuntu:

P.S. I was unsure, but think this is not a re-open of the old bug(s). So I
decided for a new report and setting Michael (systemd / old bug) and
Vincent (chrony) on CC.

Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd
Pkg-systemd-maintainers mailing list

Reply via email to