Am 16.04.2018 um 15:16 schrieb Christian Ehrhardt:
> Package: systemd
> Version: 238-4
> Hi,
> 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
> 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.


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

Attachment: signature.asc
Description: OpenPGP digital signature

Pkg-systemd-maintainers mailing list

Reply via email to