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. I start and run ntpd just the same as I run any other daemon. I use this method: http://git.busybox.net/busybox/tree/examples/var_service/README http://git.busybox.net/busybox/tree/examples/var_service/ntpd/README _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
