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

[Lennart Poettering]

On Wed, 27.08.14 09:50, Lukasz Stelmach (stlman at poczta.fm) wrote:

> 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.

I have now added a TODO list item, for a minimal service
systemd-timesync-wait.service or so, that works akin to
systemd-network-wait-online.service or so. I find this kinda ugly,
but, I figure it might have some users....

That said, I can only recommend apps who really want accurate clocks
to subscribe to time jumps via TFD_TIMER_CANCEL_ON_SET and then check
for the STA_UNSYNC flag. It's certainly much nicer.

Lennart

-- 
Lennart Poettering, Red Hat