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?
Description: OpenPGP digital signature
_______________________________________________ Pkg-systemd-maintainers mailing list Pkgemail@example.com https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-systemd-maintainers