Bug#895821: 873185 made which time service starts unreliable

[Michael Biebl]

Am 16.04.2018 um 15:16 schrieb Christian Ehrhardt:
> 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.

Maybe the best we can do is to document in README.Debian, that users of
an alternative NTP client, have to disable systemd-timesyncd manually.
The Condition is only a hack and I'd rather not add it back. It's not a
proper solution either, as it only checks for the existince of the
binaries, not if the alternative NTP services are actually running.



Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20180416/2199c81e/attachment-0002.sig>