[ntp:questions] NTPD silently not tracking
magnus at rubidium.dyndns.org
Tue Sep 3 00:22:50 UTC 2013
On 09/02/2013 12:39 AM, Harlan Stenn wrote:
> unruh writes:
>> In this case ntpd wandered off by hours with no complaint. That is not a
>> proper behaviour of a professional piece of software.
> And I don't remember the config file. If the target platform has a
> config file with setting that change the performance so the described
> behavior is possible, that's not a bug in NTP.
>> Now it could be that they have the local clock enables, and for some
>> reason ntpd chased that rather than all of the other server
>> sources. Pointing out that they should never actually use the local
>> clock as a source is certainly useful since the clock is never wrong
>> with respect to the local source.
> Again, if this is what happened and the config file directives make this
> the stated behavior, that's not a bug in the code. That's a
> configuration file problem.
Giving reasonable warnings when the config will cause a system to be
isolated is however expected. You can't expect all the users deeply
understand all twists of the configuration. A particular problem with a
software like NTPD is that so many recommendations from so many
different ages is floating around. Comprehend the full documentation can
be daunting. So it's not as easy as saying it is a configuration problem
rather than a software problem, sometimes the art of configuration of
the software IS the problem.
>> But if the computer has 5 outside source available and still chases
>> after the local source that is a bug that should be fixed. If you know
>> some attempt was made to fix a bug like than in a more recent version
>> than the one used by the user, then advising upgrade is appropriate (as
>> is telling him never to use local)
> Sure, and we will need to see the bug duplicated on the latest version
> of whatever branch has the problem, and with 4.2.8 nearly ready for
> release and with almost no chance of another 4.2.6 release, it makes
> sense for folks to focus on the latest -dev code.
> If some volunteer feels like working on this for older code that's
> great, and if somebody wants active support for older code that is
> available too.
The affected machine was a server for other things and was a client for
NTP time. There where very limited time to fool around on that machine
with latest and greatest code or whatever comes recommended hours/days
after we encountered the problem, and the core behavior was so major
that not reporting it when we saw it again would have been bad. We had
to focus on getting our system into operational state again, as that is
our primary task. I have not had the time to setup another machine to
replicate the problem with that or any other version of code.
More information about the questions