[systemd-devel] [BUG] time-sync.target reached prematurely

[Lukasz Stelmach]

On 26.08.2014 22:28, Lennart Poettering wrote:
> On Tue, 26.08.14 22:11, Lukasz Stelmach (stlman at poczta.fm) wrote:
> 
>> Greetings.
>>
>> According to systemd.special(7) "all services where correct time is
>> essential should be ordered after" time-sync.target. Implicitly this
>> means that if systemd-timesyncd is enabled services ordered after the
>> target should also get a usable network connection because the daemon
>> uses the network (not a GPS receiver like ntpd could do) to synchronise
>> the clock. However, this isn't actually the case as systemd-timesyncd
>> reports "READY=1" [1] before even checking if network is online *and*
>> querying servers. The target is reached *before* time is synced.
>>
>> How would you suggest to fix this?
> 
> Well, I guess similar to the network.target story it isn't really clear
> what "time-sync.target" is supposed to mean...
> 
> I mean, I am pretty sure we should never delay the boot by default for
> external conditions, such as network connectivity. hence, by default
> waiting for a network interface before we finish boot, and even waiting
> for a way to connect to an NTP server is not OK.
> 
> However, timesyncd actually does something before sending READY=1: it
> will bump the clock to at least the time it was when the system was
> shutdown the last time. The idea here is that RTC-less systems at least
> get strictly monotonic time, even if not a correct one.
> 
> Generally the logic is that we should try our best to provide as correct
> a time as we can, and that includes making time appear monotonic at
> least if we cannot do that. But at the same time waiting for the network
> is something that is not OK... I mean, most of the time the RTC should
> be good enough and NTP should just adjust the clock minimally, to fix
> the error the RTC might introduce...

Yes that is a point. However, the current description the man page
provides is a bit less accurate than the above. Then, the delay you
describe does not seem as bad to me as you say. Suppose we've got two
services: aiccu, systemd-logind. Their dependencies look (very) roughly
like this:


           multi-user.target
           /               \
aiccu.service---------     systemd-logind.service
          |           \     |
time-sync.target       \___basic.target
          |
          |           sysinit.target
          |          /
systemd-timesyncd.service

This means that waiting for systemd-timesyncd to contact NTP server
indeed delays reaching multi-user.target but it does not affect
systemd-logind (actually it does, because systemd-timesyncd is wanted by
sysinit.target but if it was a part of multi-user.target then it is not
a problem (time-sync-wait.service?)) or any other services that do not
depend on time-sync.target. If a service really needs "correct time"
then I assume its authors and users are aware of the fact it won't start
that instantly upon boot.

You are right saying RTC provides acceptable accuracy in most cases and
NTP is ther to correct slight errors. There are systems (distributed
filesystems?) that need sub(micro?)second accuracy provided by PTP.
Other systems may use GPS receivers which make network connectivity
unnecessary. Mobiles may use GSM network to get time (I wonder if
entering PIN is required).

All in all, IMHO, time-sync.target should be reached after synchronising
the system clock which doesn't have to mean delaying services that make
the system appear to boot fast. It appears to be easier to provide a
single target that modify many applications to check for STA_UNSYNC in a
loop.

Kind regards,
-- 
Było mi bardzo miło.                   Twoje oczy lubią mnie
>Łukasz<                                     i to mnie zgubi  (c)SNL

REKLAMA: http://ars-fabrica.eu/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20140827/ee4a53f8/attachment-0001.sig>