2015-02-18 12:30 GMT+01:00 Sven-Göran Bergh <[email protected]>: > > On 02/18/2015 12:04 PM, Guillermo Rodriguez Garcia wrote: >> >> 2015-02-18 11:16 GMT+01:00 Denys Vlasenko <[email protected]>: >>> >>> On Wed, Feb 18, 2015 at 10:10 AM, Guillermo Rodriguez Garcia >>> <[email protected]> wrote: >>>> >>>> 2015-02-18 9:45 GMT+01:00 Denys Vlasenko <[email protected]>: >>>>> >>>>> On Wed, Feb 18, 2015 at 8:38 AM, Guillermo Rodriguez Garcia >>>>> <[email protected]> wrote: >>>>>> >>>>>> I ended up using rdate on this particular case but I think it would be >>>>>> nice if ntpd could be used as described. >>>>>> >>>>>> I don't have enough knowledge about the protocol to know what are the >>>>>> implications of not waiting for the burst mode to end for option -q >>>>>> (as per Miroslav's patch). Can anyone shed some light? >>>>> >>>>> >>>>> Time will be set after 2 reply packets from one peer. >>>>> Which normally would take 2-3 seconds. >>>>> >>>>> If network is down or NTP server is not replying at all, >>>>> "ntpd -q" can still wait indefinitely. I guess the same is true >>>>> for ntpdate. >>>> >>>> >>>> In my tests, if the network is down, or the server is unreachable or >>>> does not reply, ntpdate returns almost immediately with an error >>>> message. >>>> >>>>> >>>>> If you plan for your machines to not hang at boot time >>>>> in such a case, you need to think (and test) booting >>>>> with network down. >>>> >>>> >>>> Can you provide any recommendations about this? What would be the best >>>> way to run ntpd to make sure it does not hang at boot if the network >>>> is down and/or the NTP server does not reply, but still sync the time >>>> as soon as the network is back up and/or the NTP server becomes >>>> available? >>> >>> >>> I do not try to set time super-duper-early. I don't see a particular >>> reason >>> why that is important. >> >> >> This depends on the actual application but there are many cases where >> you want at least an "approximate" time being set before the user >> application is run. For example for applications that need to schedule >> work. >> >> Note that it is not a matter of accuracy -- if there is no hardware >> RTC or the battery is dead, then the time will be completely wrong. >> >> The following would be ideal: >> >> 1. Run "something" such as ntpdate which sets an approximate time >> quickly, but that also terminates quickly if there is no network >> connectivity or NTP server does not respond >> 2. As soon as this is done, launch ntpd and leave it running in the >> background. If I am not wrong, Busybox's ntpd can be left running in >> the background mostly unattended and will just do its stuff when the >> network and NTP server is available. >> 3. Then proceed with the rest of the initialisation. >> >> So far the missing part of the puzzle is 1 :-) > > > As I understand it you are looking for q&d solution. In that case wouldn't > just something like this do the trick?
Why q&d? This is the typical (and intended) usage of ntpdate -- get the time approximately right before starting ntpd. > > busybox timeout -t 2 busybox ntpd -nqp .... > > Without a server reply ntpdate will not save you anyway. Uhm, yes I guess that's a feasible workaround but it feels a bit hackish. It would be nice if this could be done without this kind of trick :) Guillermo Rodriguez Garcia [email protected] _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
