Removing systemd-timesyncd from chrony's Conflicts directive worked. Some comments and details below, with more in the attached log.
On Thu, Aug 1, 2019 at 1:44 PM Vincent Blut <vincent.deb...@free.fr> wrote: > > On Wed, Jul 31, 2019 at 01:18:02PM -0700, Ross Boylan wrote: > >Here are some tests I wasn't able to get to earlier. > > > >On Mon, Jul 29, 2019 at 5:39 PM Vincent Blut <vincent.deb...@free.fr> wrote: > >..... > >> > >> Nevertheless, I would like you to test some things. > >> To begin with, I have an updated chrony unit file in a private git > >> branch targeting a future revision (not the next one) containing: > >> > >> Wants=time-sync.target > >> Before=time-sync.target > >> > >> That would be great if you could override the unit file currently > >> provided by chrony to add these two lines. I have no high hopes, but I’m > >> sill curious to see the result in this case. > > > >I tried it and it didn't help. I was still able to start it > >manually--I was a little concerned that since Before=time-sync.target > >would be unsatisfiable after startup it would never start. > > Thanks, it was a bit expected though. Anyway, I’ll add these two lines > to the unit file provided by chrony because according to the > time-sync.target documentation: > “Services responsible for synchronizing the system clock from a > remote source (such as NTP client implementations) should pull in > this target and order themselves before it.” It would have been nice if those instructions for time-sync.target were phrased in terms of actual systemd directs like Wants and Before instead of using seemingly ordinary English. Maybe the meaning is clear to those who know. > > >> If that does not work, just removing systemd-timesyncd.service from the > >> “Conflicts=” line in the chrony unit file may fix the issue… well I > >> think. ;-) > > > >I did systemctl disable systemd-timesyncd and now chrony runs (and > >stays running) on startup. > > Disabling systemd-timesyncd was guaranteed enough to succeed. That shows > that chrony is probably not at fault here. However, before merging this > bug report with #883241 and reassigning them to systemd, I would really > appreciate if you could check what’s happening by removing > systemd-timesyncd.service from the “Conflicts=” line in the chrony unit > file. > > Note that I would totally understand that you refuse to run some tests > again! I certainly do not want to burden you. > > If you accept to run these tests, then: > > # Reenable systemd-timesyncd > # systemctl enable systemd-timesyncd.service > > # Edit chrony’s unit file > # systemctl edit --full chrony.service > > That will invoke an editor. From there, remove > “systemd-timesyncd.service” from the “Conflicts=” line. Save & exit! I did this, also inserting the Wants=time-sync.target Before=time-sync.target directives into the new file. I left the override file that has those directives too; not sure if it gets checked if I've overridden the whole file. > > # Restart the system and report chrony’s status here (ditto for > systemd-timesyncd) See attached, which was done with systemd.log_type=debug. It also gives the contents of the configuration files. It worked properly: chrony was active on startup. Ross
root-session22l.log.gz
Description: application/gzip
