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

[Lennart Poettering]

On Fri, 24.10.14 23:13, Lukasz Stelmach (stlman at poczta.fm) wrote:

> On 24.10.2014 00:28, Lennart Poettering wrote:
> > On Thu, 23.10.14 21:24, Łukasz Stelmach (stlman at poczta.fm) wrote:
> > 
> >> +int main(int argc, char *argv[]) {
> >> +        struct timex tbuf;
> >> +        int r;
> >> +
> >> +        memset(&tbuf, 0, sizeof(tbuf));
> > 
> > Please initialize this with "= {}" while declaring, instead of using
> > memset() here.
> > 
> >> +        r = adjtimex(&tbuf);
> >> +
> >> +        while (r != TIME_OK) {
> > 
> > This check looks wrong. Should check for tbuf.status & STA_UNSYNC, no? 
> > 
> > Also, we already have the ntp_synced() call for doing this. 
> 
> Indeed. I can replace most of the code here with ntp_synced() leaving an
> "if" with a break and the sleep();
> 
> >> +                sleep(1);
> >> +                /* Unfortunately there seem to be no other way than
> >> +                polling to get this information. */
> >> +                memset(&tbuf, 0, sizeof(tbuf));
> > 
> > In this case, use zero(), it's nicer, simpler and less error prone.
> > 
> >> +                r = adjtimex(&tbuf);
> >> +        }
> > 
> > Implementing this with a sleep loop is really ugly. Can't we at least
> > calculate the expected sync time from the data returned by adjtimex()?
> 
> I don't know how to do it exactly (yet). But my guess is that when the
> system starts the information you refer are not good enough to predict
> anything?

Hmm, thinking about this some more: is STA_UNSYNC actually really what
we should be looking for? 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)? 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)? 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)?

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?

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.

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

Lennart

-- 
Lennart Poettering, Red Hat