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

Danny Mayer mayer at ntp.org
Sun Feb 15 19:01:54 UTC 2009

Martin Burnicki wrote:
> 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.

And as I said in that bug report, it's not a real fix since there are
other issues that need to be dealt with. intres has a set of problems
that need to get fixed first. 987 is just a patch for a larger set of

>> 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.

And that won't even matter when I get the changes in that I referenced
in the URL.


> Martin

More information about the questions mailing list