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

[Miroslav Lichvar]

On Tue, Aug 26, 2014 at 10:28:54PM +0200, 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...

IIRC it was originally added for the ntpdate, ntp-wait and chrony-wait
services. There were two meanings merged into one target. One was that
the clock was set from NTP (ntpdate) and the other was that the
synchronization of the clock has reached a stable state a no more
jumps in the time are expected to happen (ntp-wait, chrony-wait).

timesyncd setting it before NTP query doesn't fit well into that.

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

What services with dependency on the target do we use by default? Do
they really need it?

-- 
Miroslav Lichvar