Control: fixed -1 systemd 245.4-2 Control: fixed -1 ntp 1:4.2.8p14+dfsg-2 Hi,
On Mon, 18 Nov 2019 18:16:58 +0100 Daniel Swarbrick <daniel.swarbr...@cloud.ionos.com> wrote: > I am also witnessing multiple hosts where ntp is failing to start, > however the disable-with-time-daemon.conf file /is/ present on these > systems: > > $ dpkg -S disable-with-time-daemon.conf > systemd: > /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf > > System is buster 10.2, systemd package version 241-7~deb10u2. > > And it is clearly doing what it should: > > $ systemctl status systemd-timesyncd > ● systemd-timesyncd.service - Network Time Synchronization > Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; > enabled; vendor preset: enabled) > Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d > └─disable-with-time-daemon.conf > Active: inactive (dead) > Condition: start condition failed at Mon 2019-11-18 15:38:08 UTC; 1h > 26min ago > Docs: man:systemd-timesyncd.service(8) > > Nov 18 15:38:08 lhr-ceph02 systemd[1]: Condition check resulted in > Network Time Synchronization being skipped. > > However, ntp does not start, and doesn't even appear to log any errors. > I'm wondering if it's a race condition, caused by this in the ntp unit file: > > Conflicts=systemd-timesyncd.service > > But I would sort of expect a failure message to be logged. I have tried > to replicate the setup in a VM, however there, ntp is starting as it > should - making me suspect a race condition even more. > > On Thu, 1 Nov 2018 03:42:03 -0700 Rick Thomas <rbtho...@pobox.com> wrote: > > > Hmmm… > > > > It appears that the systemd package in stretch (9.5) has a patch for > this: > > > /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf > > > > But this is not present in buster. I believe this is fixed now since ntp and systemd-timesyncd are not conistallable. Cheers, Balint
