Bug#895821: 873185 made which time service starts unreliable
[...] So, I'm not sure if any changes to the status quo actually improve the > current situation, but I'm open to other ideas. Thanks Michael for the reply, in the meantime I also found that it seems to be no issue in most real world cases - more details on that in the LP bug. I subscribed to the upstream issue 7104 you pointed me to (thanks) but I think for this case I reported here we can close it for now and keep the status-quo for now. I might have a small chrony patch to improve how it works together with systemd-timesyncd, but that is a totally different issue. So please feel free to close this bug unless you are interested to keep it open for further discussion.
Bug#895821: 873185 made which time service starts unreliable
Am 16.04.2018 um 19:17 schrieb Michael Biebl: > 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. The only other alternative I can think of, is splitting systemd-timesyncd into a separate package, which has Conflicts/Replaces/Provides: time-daemon But that will open another can of worms. First of all, I'm not too thrilled having a separate binary package for a 44K binary. Second, we want to have systemd-timesyncd installed and enabled by default. A Recommends will not cut, as systemd is installed during early debootstrap, where Recommends are not considered. There might also be the risk, that by adding a Recommends, we trigger the uninstallation of any already installed alternative, like ntp, which would most likely not make people happy. If we don't add a Recommends though, people without having installed another alternative would suddenly not have systemd-timesyncd anymore, so we'd create a regression as well. So, I'm not sure if any changes to the status quo actually improve the current situation, but I'm open to other ideas. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#895821: 873185 made which time service starts unreliable
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? signature.asc Description: OpenPGP digital signature
Bug#895821: 873185 made which time service starts unreliable
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
