[ntp:questions] Why does ntp keep changing my conf file?

[Richard B. Gilbert]

On 9/16/2010 1:39 PM, Daniel Havey wrote:
> Well you are right.  The init.d script does something that rewrites the ntp.conf file.  I don't understand enough bash to figure it out so I just started ntp manually.  It doesn't change the ntp.conf ;^)
>
> But it doesn't work properly either ;^(
> First of all this looks fishy:
> [dhavey at node0 /etc]$ ntpq -p
>       remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>   cogsworth.aero. .INIT.          16 u    - 1024    0    0.000    0.000   0.000
>   dns.aero.org    .INIT.          16 u    - 1024    0    0.000    0.000   0.000
>
> Those delay, offset, and jitter values are too good to be true and the other machine won't connect:
> [dhavey at node1 ~]$ sudo ntpdate node0.rms01.wgs.sntb.aero.org
> 16 Sep 10:24:03 ntpdate[25389]: no server suitable for synchronization found
>
> Hmmm...
>

It not only LOOKS too good to be true, it IS to good to be true!

NTPD has not yet been able to contact either cogsworth.aero or dns.aero.org.

Also, you appear to have forced the poll interval to 1024 seconds.  1024 
is really great when your clock is within a few microseconds of the 
correct time.  It's not usually a good idea to tinker with the poll 
interval, the program will adjust the poll interval to an interval 
appropriate for the current state of the program.  Normally it will 
commence polling at a short interval and lengthen the interval as NTPD 
gains confidence in the quality of time supplied by that server.  In 
defense of the server, it almost certainly has the correct time but the 
time will be mangled in transmission.

Finally, two servers are not sufficient to allow NTPD to do its best. 
The magic numbers are four, five, or seven which allow NTPD to survive 
the failure (wrong time or no response) of one, two, or three servers, 
respectively.

The big problem with two servers is that, when the two differ, as they 
inevitably will, NTPD has no means to determine which one is more nearly 
correct.

Four, five, and seven are the magic numbers that will allow NTPD to 
survive the failure of one, two, or three servers, respectively!
Failure, here, can mean either incorrect time or no response at all.

NTPQ cannot give you much in the way of useful information until NTPD 
has been running for a minimum of thirty minutes.  NTPD can require as 
many as ten hours to achieve the accuracy of which it is capable.