On Tue, 26.08.14 22:11, Lukasz Stelmach ([email protected]) 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... Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
