ntpdate - set the date and time via NTP
Last update: March 23, 2023 21:05 UTC (6ad51a76f)
from Alice’s Adventures in Wonderland, Lewis Carroll
I told you it was eyeball and wristwatch.
Disclaimer: This program has known bugs and deficiencies and nobody has volunteered to fix them in a long time. The good news is the functionality originally intended for this program is available in the
sntp programs. See the Deprecating
ntpdate topic for a thorough discussion and analysis of the issues. See the
-q command line option in
ntpd - Network Time Protocol (NTP) daemon or
sntp - Simple Network Time Protocol (SNTP) Client. After a suitable period of mourning, the
ntpdate program will be retired from this distribution.
Table of Contents
ntpdate [ -46bBdqsuv ] [ -a key ] [ -e authdelay ] [ -k keyfile ] [ -o version ] [ -p samples ] [ -t timeout ] server [ … ]
ntpdate sets the local date and time by polling the Network Time Protocol (NTP) server(s) given as the
server arguments to determine the correct time. It must be run as root on the local host. A number of samples are obtained from each of the servers specified and a subset of the NTP clock filter and selection algorithms are applied to select the best of these. Note that the accuracy and reliability of
ntpdate depends on the number of servers, the number of polls each time it is run and the interval between runs.
ntpdate can be run manually as necessary to set the host clock, or it can be run from the host startup script to set the clock at boot time. This is useful in some cases to set the clock initially before starting the NTP daemon
ntpd. It is also possible to run
ntpdate from a
cron script. However, it is important to note that
ntpdate with contrived
cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since
ntpdate does not discipline the host clock frequency as does
ntpd, the accuracy using
ntpdate is limited.
Time adjustments are made by
ntpdate in one of two ways. If
ntpdate determines the clock is in error more than 0.5 second it will simply step the time by calling the system
settimeofday() routine. If the error is less than 0.5 seconds, it will slew the time by calling the system
adjtime() routine. The latter technique is less disruptive and more accurate when the error is small, and works quite well when
ntpdate is run by
cron every hour or two.
ntpdate will, if the
-u flag was not specified, decline to set the date if an NTP server daemon (e.g.,
ntpd) is running on the same host. When running
ntpdate on a regular basis from
cron as an alternative to running a daemon, doing so once every hour or two will result in precise enough timekeeping to avoid stepping the clock.
Note that in contexts where a host name is expected, a
-4 qualifier preceding the host name forces DNS resolution to the IPv4 namespace, while a
-6 qualifier forces DNS resolution to the IPv6 namespace.
If NetInfo support is compiled into
ntpdate, then the
server argument is optional if
ntpdate can find a time server in the NetInfo configuration for
Command Line Options
- Force DNS resolution of following host names on the command line to the IPv4 namespace.
- Force DNS resolution of following host names on the command line to the IPv6 namespace.
- Enable the authentication function and specify the key identifier to be used for authentication as the argument
key. The keys and key identifiers must match in both the client and server key files. The default is to disable the authentication function.
- Force the time to always be slewed using the
adjtime() system call, even if the measured offset is greater than +-500 ms. The default is to step the time using
settimeofday() if the offset is greater than +-500 ms. Note that, if the offset is much greater than +-500 ms in this case, that it can take a long time (hours) to slew the clock to the correct value. During this time. the host should not be used to synchronize clients.
- Force the time to be stepped using the
settimeofday() system call, rather than slewed (default) using the
adjtime() system call. This option should be used when called from a startup file at boot time.
- Enable the debugging mode, in which
ntpdate will go through all the steps, but not adjust the local clock and using an unprivileged port. Information useful for general debugging will also be printed.
- Specify the processing delay to perform an authentication function as the value
authdelay, in seconds and fraction (see
ntpd for details). This number is usually small enough to be negligible for most purposes, though specifying a value may improve timekeeping on very slow CPUs.
- Specify the path for the authentication key file as the string
keyfile. The default is
/etc/ntp.keys. This file should be in the format described in
- Specify the NTP version for outgoing packets as the integer
version, which can be
1, 2, 3 or
4. The default is
4. This allows
ntpdate to be used with older NTP versions.
- Specify the number of samples to be acquired from each server as the integer
samples, with values from
8 inclusive. The default is
- Query only - don’t set the clock.
- Divert logging output from the standard output (default) to the system
syslog facility. This is designed primarily for convenience of
- Specify the maximum time waiting for a server response as the value
timeout, in seconds and fraction. The value is rounded to a multiple of 0.2 seconds. The default is
2 seconds, a value suitable for polling across a LAN.
ntpdate to use an unprivileged port for outgoing packets. This is most useful when behind a firewall that blocks incoming traffic to privileged ports, and you want to synchronize with hosts beyond the firewall. Note that the
-d option always uses unprivileged ports.
- Be verbose. This option will cause
ntpdate’s version identification string to be logged.
ntpdate’s exit status is zero if it finds a server and updates the clock, and nonzero otherwise.
/etc/ntp.keys - encryption keys used by
The slew adjustment is actually 50% larger than the measured offset, since this (it is argued) will tend to keep a badly drifting clock more accurate. This is probably not a good idea and may cause a troubling hunt for some values of the kernel variables