ntpdate-like functionality in ntpd

[Sven-Göran Bergh]

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?

busybox timeout -t 2 busybox ntpd -nqp ....

Without a server reply ntpdate will not save you anyway.

Brgds
/S-G