On Wed, 29.10.14 17:50, Lukasz Stelmach ([email protected]) 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 _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
