On 26.08.2014 22:28, Lennart Poettering wrote: > On Tue, 26.08.14 22:11, Lukasz Stelmach (stl...@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/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel