[ntp:questions] ntpdate.c unsafe buffer write

Steve Kostecke kostecke at ntp.org
Sat Feb 9 15:16:47 UTC 2008


On 2008-02-09, Tom Smith <smith at cag.zko.hp.com> wrote:

> He means be done with it, including hard-setting the clock, within a
> second. The accuracy expected, based on "ntpdate -b" as the benchmark
> you are trying to replace, is within a small number of milliseconds of
> the specified servers.
>
> Sorry, "ntpd -q" doesn't meet the requirements.

You need to be realistic about your requirements.

In the case of systems which run time sensitive services, or are rarely
rebooted, an ~11 second pause, which is _is_ about the amount of time it
takes for 'ntpq -gq' to do a quick sanity check on your configured time
servers and set the clock, is not unreasonable.

In the case of systems which do not run time critical services there
is no reason why ntpd can not be started with -g and be allowed to set
the clock as the boot progresses. In most cases the clock will be set
before, or very shortly after, the boot sequence is completed.

The big issue in the "ntpdate vs ntpd -gq" debate is the fact that the
former may be used over unprivileged ports while the latter can not.
This gives ntpdate the advantage in situtations where a firewall is
blocking port 123/UDP.

That's what you should be complaining about, not some trivial 11 second
delay.

-- 
Steve Kostecke <kostecke at ntp.org>
NTP Public Services Project - http://support.ntp.org/




More information about the questions mailing list