[ntp:questions] ntpd, boot time, and hot plugging

David L. Mills mills at udel.edu
Sun Feb 6 22:58:00 UTC 2005


The ntpd will try forever to set the clock. Sometime next week it might 
even do that and make a correction of six days. For the daemon to find 
the clock more than 1000 s off after that, something must be seriously 
broken in the server or client and surely the daemon should abandon ship 
and wave a flag at the system log. It happened last year when some 
popular GPS radio caught a bug and jumped several years. Nobody seemed 
to notice, as ntpd dropped anchor and left the clock alone. Same thing 
happened to me when one of my radios stuck a counter bit.

Many options, including the g, q and x, as well as the tinker commands 
were put in because some folks absolutely had to have them and, except 
for the q, were against my engineering judgement. There are extended 
discussions on these and related issues in the white papers on the NTP 
project page.


Alain wrote:
> This thread has gone very complex, so I here are my coments to many 
> massages:
> -----------------
> David L. Mills escreveu:
>  > Normally, ntpd exits with a message to the system log if the offset
>  > exceeds the panic threshold, which is 1000 s by default. This option
>  > allows the time to be set to any value without restriction; however,
>  > this can happen only once. If the threshold is exceeded after that,
>  > ntpd will exit with a message to the system log. This option can be
>  > used with the -q and -x options. See the tinker command for other
>  > options.
> I do understand the explanetions. I just had missed was how things were 
> *intended* to be used.
> Now the 1000s exiting IMHO is just one more problem that I have to write 
> a script to make it work. Why does it have to exit at all? It looks just 
> a like a good way of waking up one day and ntp has stopped 20 days ago 
> an all clocks have gone havock.
> My suggestion is that there should be a "allways keep trying" option.
> ------------------
> David L. Mills escreveu:
>  > I did the same thing as you, but ntpd -gq with 8 servers and iburst
>  > set the clock in 8 seconds, not 45. This includes DNS. Did yours stall
>  > in DNS? Each of the g, q and x option descriptions has a sentence that
>  > mentions that the option can be used in conjuntion with the other two.
> I did some optimizind, but never got less that 45s with ntpd. I believe 
> that DNS was not an issue just because I did all testes repeatedly and 
> intermixed on the same machine and got consistent results.
> I just hope that before ntpdate is definitely toched, a quick start 
> (withou exist) option exist for ntpd :)
> ------------------
> Per Hedeland escreveu:
>  > [...] In the context of a special
>  > startup mode for ntpd, with ntpd resuming normal operation before that
>  > accuracy was achieved, I'm not sure I understand where this "required
>  > accuracy" would fit in... - should ntpd somehow signal the environment
>  > at the point when it was achieved?
> Well, that is desirable. In fact it was a quation in my personal queue: 
> How do I know when ntpd is ok and started serving?
> -----------
> Brad Knowles escreveu:
>  >     Switching to testing ntpd, using my ISPs upstream nameservers, I
>  > can't tell you how long it took the first time, because my system
>  > clock was so screwed up by the previous recovery that it came up with
>  > a date/time stamp in 1970, after which the execution of ntpd caused
>  > it to reset it's clock to 1934.
> I am glad to see that things like that don't happen only to me...
> Thanks all,
> Alain

More information about the questions mailing list