[ntp:questions] Re: ntpdate functions successors

David L. Mills mills at udel.edu
Tue Oct 12 02:55:51 UTC 2004


Guys,

Don't think about ntpd with crafted options as ntpdate. Think about ntpd 
running normally, but exiting when the clock is first set. Also think of 
what ntpd leaves behind, either a residual offset to be amortized by the 
adjtime() syscall or a clock step. It doesn't make good sense to step if 
the amount stepped is small, but you can tinker the step threshold to a 
nanosecond, which would have that result. Whether or not it will step or 
panic or whatever is just like vanilla ntpd.

While ntpd is running in ntpdate mode it is in fact a full-featured ntpd 
and will, unless restricted, respond to spurious client packets. It 
will, however, respond as does real ntpd when first starting up - it 
will show leap unsynchronized and stratum 16.

One of the reasons for this design is that all the crafted NTP 
algorithms are available, even public key cryptography, statistics 
files, etc. As I said before, if you want to run ntpd and not set the 
clock, put a disable ntp in the configuration file and remove the 
ntp.drift file. The peerstats, sysstats, etc., files are recorded as usual.

I have no idea why you would want to use ntpd in ntpdate mode to watch 
another server. That's what ntpq is for.

By all means, if you value ntpdate, don't hesitate to use it. All Harlan 
is saying is that it has become unmaintainable and we don't intend to 
continue supporting it here.

Dave

Harlan Stenn wrote:
>>>>1. Providing synchronized time on a host without having ntpd listening
>>>>(to exclude any possibility of being abused or exploited), typical to
>>>>unix workstations.
>>>>(ntpdate in crontab)
>>
>>HS> ntpd -q
>>
>>Does it mean ntpd really ignores any packets expect replies to its requests?
>>Or one should write a bunch of explicit restrictions?
> 
> 
> I believe that in this mode the daemon will not be in sync, so it will not
> server time.
> 
> 
>>>>2. Always use time stepping on system startup, regardless of offset value.
>>>>(ntpdate -b)
>>
>>HS> ntpd -g
>>No. At least manpage says nothing for the question whether it would do
>>_stepping_ or _adjusting_. It only says "any offset is valid".
> 
> 
> If the time is "close" it will slew (and that adjustment should happen
> in well under a second).  If the time is not close it will be stepped.
> 
> You can use the tinker variables to adjust this behavior.
> 
> The -g is primarily used to avoid the "sanity" check and update the
> clock even if the time is off by more than 1000 seconds.
> 
> 
>>>>4. Checking working of remote server and its offset, with output suitable
>>>>for machine parsing (in scripts) and without affecting current daemon.
>>>>(ntpdate -uq)
>>
>>HS> Not sure how to do this either.
>>Well, it's still required for diagnostics.
> 
> 
> I thought Dave had a solution to this problem in a previous message.
> 
> And -l stdout should make for easier parsing.
> 
> 
>>>>All listed applications are widely used in our network and it's strongly
>>>>interesting what we shall do when the main useful tool disappear.
> 
> 
> ntpdate has a number of significant bugs.
> 
> 
>>HS> ntpdate has many limitations and problems that are addressed by using
>>HS> ntpd instead.
>>ntpd was oriented to be _server_ program for too long time. I see no
>>need to change any host to be server, it's contrary to common tendence
>>which leads to provide maximal closeness.
> 
> 
> I really don't understand what you are saying.  What we describe does not
> turn hosts into time servers.
> 
> H




More information about the questions mailing list