ntpdate-like functionality in ntpd

[Guillermo Rodriguez Garcia]

2015-02-18 12:30 GMT+01:00 Sven-Göran Bergh <sgb-list+busybox at systemaxion.se>:
>
> On 02/18/2015 12:04 PM, Guillermo Rodriguez Garcia wrote:
>>
>> 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 :-)
>
>
> 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
guille.rodriguez at gmail.com