ntpd - Network Time Protocol (NTP) daemon
Synopsis
ntpd [ -aAbdm ] [ -c conffile ] [ -f driftfile ] [ -g
] [ -k keyfile ] [ -l logfile ] [ -p pidfile ] [ -r
broadcastdelay ] [ -s statsdir ] [ -t key ] [ -v
variable ] [ -V variable ] [ -x ]
Description
ntpd is an operating system daemon which sets and maintains the
system time-of-day in synchronism with Internet standard time servers.
ntpd is a complete implementation of the Network Time Protocol
(NTP) version 4, but also retains compatibility with version 3, as
defined by RFC-1305, and version 1 and 2, as defined by RFC-1059 and
RFC-1119, respectively. ntpd does most computations in 64-bit
floating point arithmetic and does relatively clumsy 64-bit fixed point
operations only when necessary to preserve the unltimate precision,
about 232 picoseconds. While the ultimate precision, is not achievable
with ordinary workstations and networks of today, it may be required
with future nanosecond CPU clocks and gigabit LANs.
The daemon can operate in any of several modes, including symmetric
active/passive, client/server broadcast/multicast and manycast. A
broadcast/multicast or manycast client can discover remote servers,
compute server-client propagation delay correction factors and configure
itself automatically. This makes it possible to deploy a fleet of
workstations without specifying configuration details specific to the
local environment.
Ordinarily, ntpd reads the ntp.conf configuration
file at startup time in order to determine the synchronization sources
and operating modes. It is also possible to specify a working, although
limited, configuration entirely on the command line, obviating the need
for a configuration file. This may be particularly appropriate when the
local host is to be configured as a broadcast/multicast client or
manycast client, with all peers being determined by listening to
broadcasts at run time.
If NetInfo support is built into ntpd, then ntpd
will attempt to read its configuration from the NetInfo if the default
ntp.conf file cannot be read and no file is specified by the -c
option.
Various internal ntpd variables can be displayed and
configuration options altered while the daemon is running using the
ntpq and ntpdc utility programs.
When ntpd starts it looks at the value of umask,
and if it's zero ntpd will set the umask to
022.
Command Line Options
- -a
- Enable authentication mode (default).
- -A
- Disable authentication mode.
- -b
- Synchronize using NTP broadcast messages.
- -c conffile
- Specify the name and path of the configuration file.
- -d
- Specify debugging mode. This flag may occur multiple times, with
each occurrence indicating greater detail of display.
- -D level
- Specify debugging level directly.
- -f driftfile
- Specify the name and path of the drift file.
- -g
- Normally, the daemon exits if the offset exceeds a 1000-s sanity
limit. This option overrides this limit and allows the time to be set to
any value without restriction; however, this can happen only once. After
that, the daemon will exit of the limit is exceeded.
- -k keyfile
- Specify the name and path of the file containing the NTP
authentication keys.
- -l logfile
- Specify the name and path of the log file. The default is the system
log facility.
- -m
- Synchronize using NTP multicast messages on the IP multicast group
address 224.0.1.1 (requires multicast kernel).
- -p pidfile
- Specify the name and path to record the daemon's process ID.
- -P
- Override the priority limit set by the operating system. Not
recommended for sissies.
- -r broadcastdelay
- Specify the default propagation delay from the broadcast/multicast
server and this computer. This is necessary only if the delay cannot be
computed automatically by the protocol.
- -s statsdir
- Specify the directory path for files created by the statistics
facility.
- -t key
- Add a key number to the trusted key list.
- -v variable
- -V variable
- Add a system variable listed by default.
- -x
- Ordinarily, if the time is to be adjusted more than 128 ms, it is
stepped, not gradually slewed. This option forces the time to be slewed
in all cases. Note: Since the slew rate is limited to 0.5 ms/s, each
second of adjustment requires an amortization interval of 2000 s. Thus,
an adjustment of many seconds can take hours or days to amortize.
The Configuration File
The ntpd configuration file is read at initial startup in order
to specify the synchronization sources, modes and other related
information. Usually, it is installed in the /etc directory,
but could be installed elsewhere (see the -c conffile
command line option). The file format is similar to other Unix
configuration files - comments begin with a # character and
extend to the end of the line; blank lines are ignored. Configuration
commands consist of an initial keyword followed by a list of arguments,
some of which may be optional, separated by whitespace. Commands may not
be continued over multiple lines. Arguments may be host names, host
addresses written in numeric, dotted-quad form, integers, floating
point numbers (when specifying times in seconds) and text strings.
Optional arguments are delimited by [ ] in the following
descriptions, while alternatives are separated by |. The
notation [ ... ] means an optional, indefinite repetition of
the last item before the [ ... ].
See the following pages for configuration and control options. While
there is a rich set of options available, the only required option is
one or more server, peer, broadcast or
manycastclient commands described in the Configuration Options
page. The Notes on Configuring NTP and Setting up a
NTP Subnet page contains an extended discussion of these options.
Configuration Options
Authentication Options
Monitoring Options
Access Control Options
Reference Clock Options
Miscellaneous Options
Files
/etc/ntp.conf - the default name of the configuration file
/etc/ntp.drift - the default name of the drift file
/etc/ntp.keys - the default name of the key file
Bugs
ntpd has gotten rather fat. While not huge, it has gotten
larger than might be desireable for an elevated-priority daemon running
on a workstation, particularly since many of the fancy features which
consume the space were designed more with a busy primary server, rather
than a high stratum workstation, in mind.
David L. Mills <mills@udel.edu>