NAME¶

ntpq - standard NTP query program

SYNOPSIS¶

ntpq [-46adhinpkwWu] [-c command] [host] [...]

DESCRIPTION¶

The ntpq utility program is used to monitor NTP daemon ntpd operations and determine performance. It uses the standard NTP mode 6 control message formats defined in Appendix B of the NTPv3 specification RFC 1305. The same formats are used in NTPv4, although some of the variable names have changed, and new ones added. The description on this page is for the NTPv4 variables.

The program can be run either in interactive mode or controlled using command line arguments. Requests to read and write arbitrary variables can be assembled, with raw and pretty-printed output options being available. It can also obtain and print a list of peers in a common format by sending multiple queries to the server.

If one or more request options are included on the command line when ntpq is executed, each of the requests will be sent to the NTP servers running on each of the hosts given as command line arguments, or on localhost by default. If no request options are given, ntpq will attempt to read commands from the standard input and execute these on the NTP server running on the first host given on the command line, again defaulting to localhost when no other host is specified. ntpq will prompt for commands if the standard input is a terminal device.

ntpq uses NTP mode 6 packets to communicate with the NTP server, and hence can be used to query any compatible server on the network which permits it. Note that since NTP is a UDP protocol this communication will be somewhat unreliable, especially over large distances in terms of network topology. ntpq makes one attempt to retransmit requests and will time requests out if the remote host is not heard from within a suitable timeout time.

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.

For examples and usage, see the NTP Debugging Techniques page.

For a simpler near-real-time monitor, see ntpmon(1).

OPTIONS¶

Command line options are described following. Specifying the command line options -c or -p will cause the specified query (queries) to be sent to the indicated host(s) immediately. Otherwise, ntpq will attempt to read interactive format commands from the standard input.

-4, --ipv4

-6, --ipv6

-a num, --authentication=num

-c cmd, --command=cmd

-d, --debug

-D num, --set-debug-level=num

-l filename, --logfile=filename

-h, --help

-n, --numeric

-s, --srcname

-S, --srcnumber

-p, --peers

-k filename, --keyfile=filename

-V, --version

-w, --wide

-W num, --width=num

-u, --units

INTERNAL COMMANDS¶

Interactive format commands consist of a keyword followed by zero to four arguments. Only enough characters of the full keyword to uniquely identify the command need be typed. The output of a command is normally sent to the standard output, but optionally the output of individual commands may be sent to a file by appending a >, followed by a file name, to the command line. Some interactive format commands are executed entirely within the ntpq program itself and do not result in NTP mode 6 requests being sent to a server. These are described as following.

? [command_keyword], help [command_keyword]

addvars name [ = value] [...]; rmvars name [...]; clearvars

authenticate [yes | no]

cooked

debug more | less | off

noflake, +doflake probability

logfile <stderr> | filename

delay milliseconds

exit

host name

hostnames [yes | no]

keyid keyid

keytype

ntpversion 1 | 2 | 3 | 4

passwd

quit

raw

timeout milliseconds

units

version

CONTROL MESSAGE COMMANDS¶

Association IDs are used to identify system, peer and clock variables. System variables are assigned an association ID of zero and system name space, while each association is assigned a nonzero association ID and peer namespace. Most control commands send a single mode 6 message to the server and expect a single response message. The exceptions are the peers command, which sends a series of messages, and the mreadlist and mreadvar commands, which iterate over a range of associations.

associations

ind assid status conf reach auth condition last_event cnt

authinfo

clockvar assocID [name [ = value [...] ][...], cv assocID [name [ = value [...] ][...]

:config [...]

config-from-file filename

ifstats

iostats

kerninfo

lassociations

lpeers [-4 | -6]

monstats

direct

mrulist [limited | kod | mincount=count | mindrop=drop | minscore=score | maxlstint=seconds | minlstint=seconds | laddr=localaddr | sort=sortorder | resany=hexmask | resall=hexmask | limit=limit | addr.num=address]

mreadvar assocID assocID [ variable_name [ = value[ ... ], mrv assocID assocID [ variable_name [ = value[ ... ]

opeers

passociations

peers

The t column has strange encodings due to historical use by old code. If you are looking at an old server, you might also see: s: symmetric (peer), server, B: broadcast server,

The tally code is one of the following:

apeers

[tally]remote refid assid st t when pool reach delay offset jitter

rpeers

pstats assocID

readvar assocID [ name ] [,...], rv assocID [ name ] [,...]

reslist

timerstats

writelist assocID

writevar assocID name = value [,...]

sysinfo

sysstats

mssntpinfo

ntsinfo

AUTHENTICATION¶

Four commands require authentication to the server: config-from-file, config, ifstats, and reslist. An authkey file must be in place and a control key declared in ntp.conf for these commands to work.

If you are running as root or otherwise have read access to the authkey and ntp.conf file, ntpq will mine the required credentials for you. Otherwise, you will be prompted to enter a key ID and password.

Credentials once entered, are retained and used for the duration of your ntpq session.

STATUS WORDS AND KISS CODES¶

The current state of the operating program is shown in a set of status words maintained by the system and each association separately. These words are displayed in the rv and as commands both in hexadecimal and decoded short tip strings. The codes, tips, and short explanations are on the Event Messages and Status Words page. The page also includes a list of system and peer messages, the code for the latest of which is included in the status word.

Information resulting from protocol machine state transitions is displayed using an informal set of ASCII strings called kiss codes. The original purpose was for kiss-o'-death (KoD) packets sent by the server to advise the client of an unusual condition. They are now displayed, when appropriate, in the reference identifier field in various billboards.

SYSTEM VARIABLES¶

The following system variables appear in the rv billboard. Not all variables are displayed in some configurations.

The jitter and wander statistics are exponentially-weighted RMS averages. The system jitter is defined in the NTPv4 specification; the clock jitter statistic is computed by the clock discipline module.

PEER VARIABLES¶

The following peer variables appear in the rv billboard for each association. Not all variables are displayed in some configurations.

CLOCK VARIABLES¶

The following clock variables appear in the cv billboard for each association with a reference clock. Not all variables are displayed in some configurations.

COMPATIBILITY¶

When listing refids, addresses of the form 127.127.x.x are no longer automatically interpreted as local refclocks as in older versions of ntpq. Instead, a clock-format display is requested by the NTPsec daemon when appropriate (by setting the srcaddr peer variable). This means that when used to query legacy versions of ntpd, which do not know how to request this, this program will do a slightly wrong thing.

In older versions, the type variable associated with a reference clock was a numeric driver type index. It has been replaced by name, a shortname for the driver type.

In older versions, no count of control packets was listed under sysstats.

The -O (--old-rv) option of legacy versions has been retired.

KNOWN LIMITATIONS¶

It is possible for a ":config unpeer" command to fail silently, yielding "Config Succeeded", if it is given a peer identifier that looks like a driver type name or a hostname not present in the peer list. The error will, however, be reported in the system log.

The config command cannot be used to change a server’s default restrictions.

Under some circumstances python 2 cannot emit unicode. When true, the display of units is downgraded to non-unicode alternatives. One place a user is likely to encounter this is when diverting output through a pipe. Attempts have been made to force the use of UTF-8, all of which break the command history feature.

When using the -u option, very old xterms may fail to render μ correctly. If this happens, be sure your xterm is started with the -u8 option, or the utf8 resource', and that your console font contains the UTF-8 μ character. Also confirm your LANG environment variable is set to a UTF-8 language, like this: "export LANG=en_US.utf8".

Timestamp interpretation in this program is likely to fail in flaky ways if the local system clock has not already been approximately synchronized to UTC. Querying a server based in a different NTP era than the current one is especially likely to fail.

This program will behave in apparently buggy and only semi-predictable ways when fetching MRU lists from any server with sufficiently high traffic.

The problem is fundamental. The Mode 6 protocol can’t ship (and your client cannot accept) MRU records as fast as the daemon accepts incoming traffic. Under these circumstances, the daemon will repeatedly fail to ship an entire report, leading to long hangs as your client repeatedly re-sends the request. Eventually the Mode 6 client library will throw an error indicating that a maximum number of restarts has been exceeded.

To avoid this problem, avoid monitoring over links that don’t have enough capacity to handle the monitored server’s entire NTP load.

You may be able to retrieve partial data in very high-traffic conditions by using the direct option.

EXIT STATUS¶

One of the following exit values will be returned:

0 (EXIT_SUCCESS)

1 (EXIT_FAILURE)