Bug#805927: timesyncd does not automatically start after removing all NTP daemons

[Josh Triplett]

On Tue, Nov 24, 2015 at 02:14:19PM +0100, Michael Biebl wrote:
> Hi Josh
> Am 24.11.2015 um 06:53 schrieb Josh Triplett:
> > Package: systemd
> > Version: 228-2
> > Severity: wishlist
> > 
> > /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
> > disables systemd-timesyncd if /usr/sbin/ntpd (or another NTP daemon)
> > exists.  However, nothing causes systemd-timesyncd to automatically
> > start running after removing the last such daemon.  Would you consider
> > adding such a mechanism?  (For instance, you could add a trigger in
> > systemd that registers interest in the paths listed in
> > disable-with-time-daemon.conf.)
> 
> We want to get rid of those hard-coded paths, not add them to more places.
> 
> > The reverse holds true as well: if you install such a daemon,
> > systemd-timesyncd does not automatically stop.
> 
> The idea here is, that ntp, etc ship native service files, which have
> Conflicts=systemd-timesyncd.service. So installing them should actually
> stop timesyncd.

That seems preferable, sure.  And that fixes half the problem, but as
far as I understand the semantics of Conflicts, not the other half.

> As for starting timesyncd automatically whenever ntp is removed: I have
> to say, I don't particularly like the idea of installing dpkg triggers
> for that. I mean, it wouldn't be too hard to manually start timesyncd.
> Or on next reboot it would be started anyway.

Having to manually start timesyncd, or reboot, seems inconsistent with
the amount of automatic "just works" typically found in daemon packages.
If Debian normally didn't start daemons on package installation, then
I'd agree, but it does.

Unfortunately (or perhaps fortunately) systemd doesn't automatically
watch unit files and treat Conflicts like an "inhibit".

Does some other means exist to notice this change and DTRT?

- Josh Triplett