Bug#895821: 873185 made which time service starts unreliable
Christian Ehrhardt
christian.ehrhardt at canonical.com
Mon Apr 16 14:16:15 BST 2018
Package: systemd
Version: 238-4
Hi,
in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873185 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 https://github.com/systemd/systemd/issues/8730 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
started.
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: https://bugs.launchpad.net/systemd/+bug/1764357
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180416/340e1de6/attachment.html>
More information about the Pkg-systemd-maintainers
mailing list