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

[Lennart Poettering]

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

Lennart

-- 
Lennart Poettering, Red Hat