alternative approach to waiting for system time to be set

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux