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

[Lukasz Stelmach]

On 27.10.2014 15:12, Lennart Poettering wrote:
> 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 can image users who would.

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

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

> 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

and unlink it here

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

and of upon exit. An erroneous one too.

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

-- 
Było mi bardzo miło.                   Twoje oczy lubią mnie
>Łukasz<                                     i to mnie zgubi  (c)SNL

REKLAMA: http://ars-fabrica.eu/ sklep z rękodziełem

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 538 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20141029/2460890e/attachment.sig>