On Tue, Jul 30, 2019 at 12:57 PM Vincent Blut <vincent.deb...@free.fr> wrote: > > On Tue, Jul 30, 2019 at 12:05:23AM -0700, Ross Boylan wrote: > >See below. > > > >On Mon, Jul 29, 2019 at 5:39 PM Vincent Blut <vincent.deb...@free.fr> wrote: > >.... > >> Hello Ross, > >> > >> On Mon, Jul 29, 2019 at 12:13:16PM -0700, Ross Boylan wrote: > >.... > >> >It looks as if systemd-timesyncd is creating a stop job for chrony > >> >even though the former includes > >,,,, > >> > >> What’s the status of systemd-timesyncd here? Is it started? > > > >I'm never sure with systemd exactly which things I should focus on for > >the status, but the results below see to indicate systemd-timesyncd is > >not running even though it's enabled. The start condition failed, > >which I gather is not quite good enough to assure it never started. > > > >root@barley:~# 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-07-29 12:35:49 PDT; 11h ago > > └─ ConditionFileIsExecutable=!/usr/sbin/chronyd was not met > > Docs: man:systemd-timesyncd.service(8) > > > >Jul 29 12:35:49 barley systemd[1]: Condition check resulted in Network > >Time…ped. > >Hint: Some lines were ellipsized, use -l to show in full. > > For the avoidance of doubt, this is the result right after booting your > system?
I ran the commands immediately above well after the start of the system, though I think they were the same just after the start. However, I had manually started chrony before getting the previous output. > Anyway, this is the expected state. > > >> Also, could you attach the output of: > >> $ systemctl show systemd-timesyncd.service > > > >root@barley:~# date; systemctl show systemd-timesyncd.service > > [snip…] > > Nothing seems suspicious here. However, I observe that systemd-timesyncd > is pulled in way earlier than chronyd (and all other NTP implementation > provided in Debian) in the boot process. This is due to its unit file > which contains sysinit.target in the “Before=” dependency directive. > > >> Thanks for these logs. To have a bigger picture, could you please ...... > > So far, the initial transactions seem correctly done: > ↳systemd-timesyncd.service starts before sysinit.target Except, at least in my reading of the man page, it should never start because one of its conditions fails. You pointed to a bug saying it doesn't actually work that way. I've run into other problems with services starting before all filesystems were mounted; I wonder if that's an issue here (not on the machine right now). i.e., /usr isn't mounted when timesync first checks for chrony, and so it thinks things are OK. > ↳units conflicting with systemd-timesyncd are stopped > ↳multi-user.target starts > ↳chrony.service starts > ↳systemd-timesyncd.service stops > > >Jul 29 11:30:43 barley systemd[1]: Found redundant job > >systemd-timesyncd.service/stop, dropping from transaction. > >Jul 29 11:30:43 barley systemd[1]: chrony.service: Installed new job > >chrony.service/start as 163 > >Jul 29 11:30:43 barley systemd[1]: run-systemd-timesync.mount: Collecting. > >Jul 29 11:30:43 barley systemd[1]: var-lib-systemd-timesync.mount: > >Collecting. > >Jul 29 11:30:44 barley systemd-sysusers[599]: Group systemd-timesync > >already exists. > >Jul 29 11:30:44 barley systemd-sysusers[599]: User systemd-timesync > >already exists. > >Jul 29 11:30:46 barley systemd[1]: Pulling in > >systemd-timesyncd.service/start from sysinit.target/start > > And here we can see that before starting sysinit.target (again), > systemd-timesyncd.service is started. > > >Jul 29 11:30:46 barley systemd[1]: Added job > >systemd-timesyncd.service/start to transaction. > >Jul 29 11:30:46 barley systemd[1]: Pulling in system.slice/start from > >systemd-timesyncd.service/start > >Jul 29 11:30:46 barley systemd[1]: Pulling in var.mount/start from > >systemd-timesyncd.service/start > >Jul 29 11:30:46 barley systemd[1]: Pulling in -.mount/start from > >systemd-timesyncd.service/start > >Jul 29 11:30:46 barley systemd[1]: Pulling in time-sync.target/start > >from systemd-timesyncd.service/start > >Jul 29 11:30:46 barley systemd[1]: Pulling in shutdown.target/stop > >from systemd-timesyncd.service/start > >Jul 29 11:30:46 barley systemd[1]: Pulling in chrony.service/stop from > >systemd-timesyncd.service/start > > systemd-timesyncd.service wants chrony.service to be stopped to > continue. I didn't get that from the config files. For timesyncd they seemed to say it shouldn't start if chrony was present, not that chrony should stop. However, chrony's files say it should not run if timesyncd (or several other timeservices) is running. > > >Jul 29 11:30:46 barley systemd[1]: Added job chrony.service/stop to > >transaction. > >Jul 29 11:30:46 barley systemd[1]: chrony.service: chrony.service/stop > >would change existing job. > >Jul 29 11:30:46 barley systemd[1]: chrony.service: Deleting > >chrony.service/stop to minimize impact. > > Here I’m not sure about what’s happening. I *think* that systemd rejects > the request for the chrony.service to be stopped. I thought it was rejecting the request because it knows it already has received a stop request. My knowledge of systemd is meager, and so you should weight my statements accordingly :) Nothing more to add and so I'll snip the rest. It's weird how it seems to be looping, but maybe those are multiple log entries for the same event? Thanks for your offer of help on the overrides. I think I know how to do it, but I do have one question: if I override the Conflicts: does the override line replace the previous one, or just supplement it? I.e., if I do an override of Conflicts without systemd-ttimesyncd, will the default conflict be forgotten? Ross
