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.
