Bug#933370: chrony won't start

[Vincent Blut]

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.”

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.

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






# systemctl revert chrony.service

# If you chose the revert option, disable systemd-timesyncd again
# systemctl disable systemd-timesyncd.service

Hope that helps!

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. That will invoke an editor. From there, remove “systemd-timesyncd.service” from the “Conflicts=” line. Save & exit! # Restart the system and report chrony’s status here (ditto for systemd-timesyncd) # If chrony is correctly running, you have the choice to leave things as # they are, but if you want to revert the chrony unit file to what it # was, run:

Here are some logs and status info from what happened with the
override in place and
debug systemd.log_level=debug as kernel options (but none of the other
options I used before).
This also shows that status of systemd-timesyncd right after startup.
This is from before I disabled systemd-timesyncd.service.

root@barley:~# date; uptime
Wed 31 Jul 2019 12:51:18 PM PDT
12:51:18 up 2 min, 11 users,  load average: 6.08, 2.93, 1.12
root@barley:~# systemctl status chrony
[snip…]

root@barley:~# systemctl status systemd-timesyncd
[snip…]

Indeed, we can that pulling in time-sync.target and starting chrony before it is insufficient. As said previously, I did not have high hopes though.

Ross

Cheers,
Vincent

signature.asc
Description: PGP signature