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?
busybox timeout -t 2 busybox ntpd -nqp ....
Without a server reply ntpdate will not save you anyway.
Brgds
/S-G
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox
