On 27.10.2014 15:12, Lennart Poettering wrote: > On Fri, 24.10.14 23:13, Lukasz Stelmach (stl...@poczta.fm) wrote: > >> On 24.10.2014 00:28, Lennart Poettering wrote: >>> On Thu, 23.10.14 21:24, Łukasz Stelmach (stl...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel