[systemd-devel] [PATCH] Add timesync-wait tool

[Lennart Poettering]

On Wed, 29.10.14 17:50, Lukasz Stelmach (stlman at poczta.fm) wrote:

> > I mean, what is the tool supposed to be
> > waiting on: that the time is set as accurately as possible (in that
> > case watching STA_UNSYNC sounds good, plus waiting for
> > TFD_CANCEL_ON_SET for big jumps and guessing sleep times from
> > adjtimex()'s return values for smaller jumps)?
> 
> There is no point in "guessing". Clearing STA_UNSYNC takes one
> timesynced cycle (32s, see below).

Well, the algorithm I was envisioning there would be one which
wouldn#t strictly be tied to timesycnd being the NTP server. By
checking what adjtimex returns I figure we could guess when the fix is
likely to be done.

> > Or that the time is set
> > accurately enough for adjtimex() to be used for the remaining accuracy
> > (In that case, we'd actually have to make timesyncd report this
> > information to us, maybe using a flag file to watch via inotify)?
> 
> This is probably what satisfies most users.
>
> > Or
> > that the time set accurately enough to be monotonic, but not more (in
> > that case just ordering after systemd-timesyncd.service should be
> > enough, no need for any other tool)?
> 
> timesyncd sends READY=1 quite early. I think it is before it tries to
> contact time servers.

Yes. And that's really the right thing to do. In normal setups we
really should not wait for external conditions.

> > Of these three options, I think the first one is not necessarily a
> > good idea, since adjtimex() is really about making time corrections
> > smooth and hence slow. Making this slow, and trying to wait for it is
> > kinda contradictory, no?
> 
> Not really, that is it isn't that slow. I measured it. First I set the
> current time off by less than a minute then waited
> 
> date $(date +%m%d%H%M%Y) && sleep 2 && time ./systemd-timesync-wait
> 
> and it always took one timesyncd cycle (32 seconds) to clear STA_UNSYNC.
> 
> How about waiting for either a flag-file which timesyncd creates after
> a few seconds timesynced is started or, if a user chooses so, for the
> "real" synchronisation?
> 
> > The third one is not a good idea either, since we already have
> > functionality covering that.
> > 
> > But if the second option is the relevant one, then I figure neither
> > adjtimex() nor TFP_CANCEL_ON_SET will be useful to us, and instead we
> > need to teach systemd-timesyncd some flag file stuff.
> 
> Yes, like "hey I've already received the time from an NTP server and fed
> it to the kernel".
> 
> Create /run/systemd/timesyncd/synchronised here:
> 
> http://cgit.freedesktop.org/systemd/systemd/tree/src/timesync/timesyncd-manager.c?id=v217#n389

Correct.

> and unlink it here
> 
> http://cgit.freedesktop.org/systemd/systemd/tree/src/timesync/timesyncd-manager.c?id=v217#n293

Sure? (see below)

> and of upon exit. An erroneous one too.

Hmm, why remove it on exit or on time change? I mean, I figure this
really should be a one-time thing: a way how the tool can wait until
the first sync is acquired, and that's it.

> 
> >>> The same way as network-wait-online has a timeout this tool should
> >>> probably have one too.
> >>
> >> If the timeout is reached the tool exits with a non-zero code. Right?
> >> That makes sense. Is three minutes OK?
> > 
> > I'd use the same default timeout as for systemd-network-wait-online,
> > for whatever that is.
> 
> Are you sure there is a timeout? The service type is oneshot (timeout is
> disabled according to systemd.service(5)) without any Timeout* set. Two
> calls to sd_event_exit() in the code depend manager_all_configured() and
> no sign of any timer.

Indeed. It really should have one though. Added to TODO list now.


Lennart

-- 
Lennart Poettering, Red Hat