Post by Peter A. Bigot Post by Lennart Poettering
Would be great if you could rework it accordingly and submit it as PR.
I've addressed most of the review comments but before pushing a new version
want to make a change that this proposes very visible, as it affects naming
and documentation which is tedious to change multiple times.
In this PR, time-sync.target is no longer a Wants= dependency of
systemd-timesyncd. The rationale is that simply starting timesyncd does not
satisfy the expectations for this synchronization point: setting the clock
to what the local time was on last shutdown is problematic, as noted in
issue #5097, and also seems to violate the spirit of LSB $timer which
implies a After=time-sync.target.
Instead that dependency is moved to the new service, which blocks until the
kernel has noted that the time is synchronized (not merely set).
I am pretty sure that both units should pull in time-sync.target, and
order themselves before it. Note that systemd-timesyncd.service will
will do something useful too when started, as it will ensure clock
monotinicity, as it saves/restores a timestamp file in /var.
The way I see it people have two options here: rely on the weaker time
syncronization rule that timesyncd itself provides or the strong one
that your new service introduces — at the cost of depending on an
external time source. If people enable the new service they get the
latter, if they don't they should still get the former. Hence both
should order themselves time-sync.target, and pull it in. And only if
all of the two that are enabled finish any other unit depending on it
This is somewhat similar to network-online.target logic, where it's
also up to the user ultimately with what kind of "online" meaning they
want to fill it.
If this change is acceptable, then I think the new service should be called
systemd-time-wait-synchronized (analogous to systemd-networkd-wait-online,
as Lennart suggested) as it has nothing to do with timesyncd. Further, it
should have its own build option so it can be enabled independently of
timesyncd (e.g. on embedded systems that will use ntpd with GPS to set the
Well, even though you could use them separately, and we should support
that if it's easy to I doubt we need to clarify that in the naming. I
mean, other NTP implementations are likely to have their own
implementations of such wait functionality (I think at least chrony
has?), and they might do different stuff on top of waiting for the
mere NTP sync bit in the kernel, hence I doubt there's too much value
in making our implementation overly generic.
Lennart Poettering, Red Hat