[systemd-devel] alternative approach to waiting for system time to be set
Peter A. Bigot
pab at pabigot.com
Tue Mar 20 13:54:47 UTC 2018
On 03/20/2018 12:57 AM, Peter A. Bigot wrote:
> On 03/19/2018 04:17 PM, Lennart Poettering wrote:
>> Would be great if you could rework it accordingly and submit it as PR.
>
> https://github.com/systemd/systemd/pull/8494
>
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).
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 system time).
If this change is not acceptable, then a new synchronization point named
something like "time-sync-for-reals.target" should be defined, and
that's starting to look ugly.
What do y'all think?
Peter
References:
* http://refspecs.linuxbase.org/LSB_2.0.1/LSB-PDA/LSB-PDA/facilname.html
More information about the systemd-devel
mailing list