[ntp:questions] ntpdate works, but ntpd doesn't (reach = 0)

Martin Burnicki martin.burnicki at meinberg.de
Fri Feb 13 12:29:12 UTC 2009


Danny Mayer wrote:
> Martin Burnicki wrote:
>> Danny Mayer wrote:
>>> Uwe Klein wrote:
>>>> Richard B. Gilbert wrote:
>>>>> Uwe Klein wrote:
>>>>>> See:
>>>>>> currently on SuSE systems 'rcntpd restart' is run on any interface
>>>>>> changes.
>>>>> Looks like a SuSE problem rather than an ntpd problem!
>>>> Not really distribution specific. Look into the ip_up/down stuff
>>>> on any linux system.
>>>>
>>>> Its a dynamic IP problem and its a ntpd problem due to no
>>>> signaling path for interface changes.
>>>> ( there have been some improvements very recently? )

Yes, in ntp-dev. See bug 992:
https://support.ntp.org/bugs/show_bug.cgi?id=992

The new code should receive interface change messages from the kernel, so
ntpd could react immediately after an interface has changed. This should be
what the Linux distributers have been waiting for.

However, I haven't tried this, yet.

>>>> uwe
>>> ntp 4.2.4 supports dynamic interfaces even if it cannot detect the
>>> change directly. The O/S does not need to worry about this for ntpd.
>> 
>> This is only supported kind of reasonably since 4.2.4p5. In earlier
>> versions it may have taken very long time after an interface has appeared
>> until ntpd re-tried to use it and mobilize associations.
>> 
> 
> It really makes no difference, especially once ntpd is stable. The
> default is every 5 minutes and you can change that with the -u
> command-line option.

Right, it may not make much difference if the interface changes *after*
associations have been mobilized, and thus ntpd already had a chance to
stabilize.

However, an additional issue has been in cases where no interface had been
up when ntpd was started. The DNS resolver retried starting at a 60s
interval, but was doubling the interval after each unsuccessful retry, so
the longer ntpd has been running before an interface became available the
longer it took until DNS lookup was retried after a new interface had
become available and been detected by ntpd.

So the symptom was that you start ntpd on your laptop, then some time later
you connect the network cable and thus an interface becomes available,
which was detected up to 5 minutes later by ntpd. 

However, it could have taken up to 16 minutes (!) after the interface had
been detected until DNS was retried an thus an association could have been
established for a server configured by host name.

This has been handled in bug 987:
https://support.ntp.org/bugs/show_bug.cgi?id=987

The fix for this which improved the behaviour at least a little bit was in
4.2.4p5.

>> So there's no wonder why the Linux distributors tried to implement some
>> workarounds (e.g. control ntpd from ifup/ifdown) to speed things up.
>> 
> 
> That's because they didn't realize that it's no longer necessary.

Maybe they had just stopped hoping this could ever been fixed ...
 
>> There are *not* only servers running 24/7 which use NTP.
>> 
> 
> I know that. My laptop never shuts down. It changes IP addresses all the
> time as I move from office to conference room and back again and then
> home.

As mentioned above there should be no problem with this as long as the
upstream servers' IP addresses have already been resolved.

Martin
-- 
Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont
Germany




More information about the questions mailing list