chrony takes some time to sync with NTP servers ... when started via systemd (maybe also with openrc) this takes some time and if we don't define a time-sync.target for other services to rely on, some other services might start with a wrong time (which is corrected soon after and leads to problems). I noticed this with net-misc/dhcp (in peer-mode) ... dhcpd.service should wait for time-sync.target. As I didn't find a chrony-wait.service in portage or bgo ... I suggest using the mentioned unit-file. Reproducible: Always # cat /etc/systemd/system/chrony-wait.service [Unit] Description=Wait for chrony to synchronize system clock After=chronyd.service Requires=chronyd.service Before=time-sync.target Wants=time-sync.target [Service] Type=oneshot # Wait up to ~10 minutes for chronyd to synchronize and the remaining # clock correction to be less than 0.1 seconds ExecStart=/usr/bin/chronyc waitsync 60 0.1 RemainAfterExit=yes [Install] WantedBy=multi-user.target
additional note for another service (should be another bug, yes ...): net-mail/dovecot is also quite sensitive to big timesteps ... should then also rely on time-sync.target --- thanks.
And more slightly off-topic but related to chronyd and systemd as well: I get systemd[1]: [/usr/lib64/systemd/system/chronyd.service:8] Unknown lvalue 'ControlGroup' in section 'Service' As far as I googled the ControlGroup= setting has been removed. So I suggest removing that line: # cat chronyd.service [Unit] Description=Chrony Network Time Service After=ntpdate.service sntp.service network.target Conflicts=ntpd.service [Service] ExecStart=/usr/sbin/chronyd -r -s -d [Install] WantedBy=multi-user.target
Not sure how ended the way to check for networking being really connected with systemd, @systemd? :/
What happens if chrony has not synced the clock to within 0.1 seconds by the time the 10 minute timeout has elapsed? I assume chronyc would exit with non-zero status, and this unit would fail. Would time-sync.target still be reached in that case? Other than that, this unit seems reasonable, so long as it is optionally enabled by the sysadmin.
(In reply to Mike Gilbert from comment #4) > What happens if chrony has not synced the clock to within 0.1 seconds by the > time the 10 minute timeout has elapsed? > > I assume chronyc would exit with non-zero status, and this unit would fail. > Would time-sync.target still be reached in that case? > > Other than that, this unit seems reasonable, so long as it is optionally > enabled by the sysadmin. We could use other values, sure. And yes, only as an option. I can test if chronyc exits with errorcode (maybe it's even in the manpages) but right now I am too busy with other things.
BUMP - how to proceed here?
(In reply to Stefan G. Weichinger from comment #6) > BUMP - how to proceed here? I believe you volunteered to do some testing. How did that go?
correct pong for my ping ;-) I will rethink what and how to test exactly (I also haven't looked at this issue for months). Your corner-case sounds valid ... but maybe much less likely in comparison to not having time-sync.target at all.
I suspect the maintainer here is not interested, so re-assigning to the systemd team. Hopefully we will get to it soonish.
additional info: I seem to have copied the suggested file from a fedora installation. Both the target and the service are used there.
bumping here silently ;-) no hurry from my side, I just want to show that I care for the bugs I file :-)
Maybe sending pull requests could help a bit to speed things a bit as usual, this kind of modifications are pretty small (add a new revision adding the one or two lines needed to install the relevant unit file) :/
(In reply to Pacho Ramos from comment #12) > Maybe sending pull requests could help a bit to speed things a bit as usual, > this kind of modifications are pretty small (add a new revision adding the > one or two lines needed to install the relevant unit file) :/ ok will do. beginners question: where to send the PR?
suggested ebuild here: https://github.com/stefangweichinger/gentoo-overlay/tree/master/net-misc/chrony
Please attach patches.
Created attachment 414952 [details] chrony-wait.service
Created attachment 414954 [details, diff] patch against chrony-2.1.1.ebuild
(In reply to Mike Gilbert from comment #9) > I suspect the maintainer here is not interested, so re-assigning to the > systemd team. Hopefully we will get to it soonish. Maintainers are assignees of packages, not random people charged to fix issues.
PR: https://github.com/gentoo/gentoo/pull/3776
I wrote here, I did a PR at github, they closed my PR and pointed me back here. Sorry, losing interest.