Copyright (C) 2000-2012 |
Manpages NTPDSection: Network Time Protocol Daemon (1)Updated: November 17, 1999 Index Return to Main Contents NAMEntpd - Network Time Protocol (NTP) daemon.SYNOPSISntpd [ -aAbdm ] [ -c conffile ] [ -f driftfile ] [ -k keyfile ] [ -l logfile ] [ -p pidfile ] [ -r broadcastdelay ] [ -s statsdir ] [ -t key ] [ -v variable ] [ -V variable ]DESCRIPTIONntpd 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 ultimate 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 ntpd utility programs. When ntpd starts it looks at the value of umask, and if it is zero ntpd will set the umask to 0222. OPTIONS
THE CONFIGURATION FILEThe 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 optionally 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 [ ... ].While there is a rich set of options available, the only required option is one or more of the server, peer, broadcast or manycastclient commands. Following is a description of the NTPv4 configuration commands. These commands have the same basic functions as in NTPv3 and in some cases new functions and new operands. The various modes are determined by the command keyword and the type of the required IP address. Addresses are classed by type as (s) a remote server or peer (IP class A, B and C), (b) the broadcast address of a local interface, (m) a multicast address (IP class D), or (r) a reference clock address (127.127.x.x). Note that, while autokey and burst modes are supported by these commands, their effect in some weird mode combinations can be meaningless or even destructive.
For type s addresses (only), this operates as the current peer command which mobilizes a persistent symmetric-active mode association, except that additional modes are available. This command should NOT be used for type b, m or r addresses. The peer command specifies that the local server is to operate in symmetric active mode with the remote server. In this mode, the local server can be synchronized to the remote server and, in addition, the remote server can be synchronized by the local server. This is useful in a network of servers where, depending on various failure scenarios either the local or remote server may be the better source of time.
For type s and r addresses, this operates as the NTPv3 server command which mobilizes a persistent client mode association. The server command specifies that the local server is to operate in client mode with the specified remote server. In this mode, the local server can be synchronized to the remote server, but the remote server can never be synchronized to the local server.
For type b and m addresses (only), this operates as the current NTPv3 broadcast command, which mobilizes a persistent broadcast mode association, except that additional modes are available. Multiple commands can be used to specify multiple local broadcast interface (subnets) and/or multiple multicast groups. Note that local broadcast messages go only to the interface associated with the subnet specified but multicast messages go to all interfaces. In the current implementation, the source address used for these messages is the Unix host default address. In broadcast mode, the local server sends periodic broadcast messages to a client population at the address specified, which is usually the broadcast address on (one of) the local network(s) or a multicast address assigned to NTP. The IANA has assigned the multicast group address 224.0.1.1 exclusively to NTP, but other nonconflicting addresses can be used to contain the messages within administrative boundaries. Ordinarily, this specification applies only to the local server operating as a sender; for operation as a broadcast client, see the broadcastclient or multicastclient commands below.
For type m addresses (only), this mobilizes a manycast client-mod association for the multicast address specified. In this case specific address must be supplied which matches the address used on th manycastserver command for the designated manycast servers. The NT multicast address 224.0.1.1 assigned by the IANA should NOT be used unless specific means are taken to avoid spraying large areas of th Internet with these messages and causing a possibly massive implosion o replies at the sender The manycast command specifies that the local server is to operate i client mode with the remote server that are discovered as the result o broadcast/multicast messages. The client broadcasts a request message to the group address associated with the specified address an specifically enabled servers respond to these messages. The client selects the servers providing the best time and continues as with the server command. The remaining servers are discarded as if never heard These four commands specify the time server name or address to be use and the mode in which to operate. The address can be either a DNS name or a IP address in dotted-quad notation. Additional information on association behaviour can be found in the Association Management page
The file format consists of a single line containing a single floating point number, which records the frequency offset measured in parts-per-million (PPM). The file is updated by first writing the current drift value into a temporary file and then renaming this file to replace the old version. This implies that ntpd must have write permission for the directory the drift file is located in, and that file system links, symbolic or otherwise, should be avoided.
FILES
BUGSNtpd has gotten rather fat. While not huge, it has gotten larger than might be desirable 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.AUTHORDavid L. Mills <mills@udel.edu>. Manpage abstracted from the html documentation by Peter Breuer <ptb@it.uc3m.es>.
IndexThis document was created by man2html, using the manual pages. Time: 21:06:36 GMT, November 11, 2024 |