ntpdate-like functionality in ntpd

[Guillermo Rodriguez Garcia]

2015-02-18 11:16 GMT+01:00 Denys Vlasenko <vda.linux at googlemail.com>:
> On Wed, Feb 18, 2015 at 10:10 AM, Guillermo Rodriguez Garcia
> <guille.rodriguez at gmail.com> wrote:
>> 2015-02-18 9:45 GMT+01:00 Denys Vlasenko <vda.linux at googlemail.com>:
>>> On Wed, Feb 18, 2015 at 8:38 AM, Guillermo Rodriguez Garcia
>>> <guille.rodriguez at gmail.com> 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 :-)

BR,

Guillermo Rodriguez Garcia
guille.rodriguez at gmail.com