Installing chrony with timesyncd running (the default) is what triggers the "both running" situation.
I have fixed this in the past, something must have changed to open this issue again.
A restart on systemd-timesyncd would detect and stop it.
Must be due to:
45 chrony (3.5-6) unstable; urgency=medium
46
47 * debian/chrony.service:
48 - Don’t conflict with systemd-timesyncd.service.
49 A few users complain that chronyd does not start at boot. The way the
50 Conflict= directive works internally might cause both systemd-timesyncd
51 and chronyd to be inactive at boot. So by relying solely on the
52 disable-with-time-daemon.conf drop-in file provided by systemd, we should
53 get rid of this malfunction while still preventing these two time daemons
54 from being active at the same time. Kudos notably go to Santiago Vila for
55 the report and providing SSH access to a GCE instance where the issue was
56 reproducible and Michael Biebl for debugging. (Closes: #947936)
Installing chrony with timesyncd running (the default) is what triggers the "both running" situation.
I have fixed this in the past, something must have changed to open this issue again.
A restart on systemd-timesyncd would detect and stop it.
Must be due to: chrony. service: timesyncd. service. with-time- daemon. conf drop-in file provided by systemd, we should
45 chrony (3.5-6) unstable; urgency=medium
46
47 * debian/
48 - Don’t conflict with systemd-
49 A few users complain that chronyd does not start at boot. The way the
50 Conflict= directive works internally might cause both systemd-timesyncd
51 and chronyd to be inactive at boot. So by relying solely on the
52 disable-
53 get rid of this malfunction while still preventing these two time daemons
54 from being active at the same time. Kudos notably go to Santiago Vila for
55 the report and providing SSH access to a GCE instance where the issue was
56 reproducible and Michael Biebl for debugging. (Closes: #947936)