Dies ist eine alte Version des Dokuments!
NTP-Zeitserver mit chrony unter Linux einrichten und nutzen
Basis für eine zuverlässige Kommunikation zwischen netzwerkbasierten Diensten und Servern ist unter anderem eine exakte Zeitmessung. Nur so kann gewährleistet werden das Systemkomponenten wie z.B. systemd-Timer und Cronjobs zur richtigen Zeit gestartet werden und laufen. Einzelne Systeme können mit Hilfe des Network Time Protocol kurz NTP ihre Systemzeiten mit einem zentralen Zeitserver oder einem Pool von Servern zu synchronisieren. NTP wurde 1985 von David L. Mills entwickelt und wurde als RFC 958 definiert um eine zuverlässige Zeitgabe über Netzwerke mit variabler Paketlaufzeit über das verbindungslose Protokolls UDP zu ermöglichen und bekam von der Internet Assigned Numbers Authority den UDP-Ports 123 zugewiesen. Das RFC958 wurde in den letzten Jahren mehrfach überarbeitet und ergänzt und wurde letztmalig mit RFC 9109 - Network Time Protocol Version 4: Port Randomization ergänzt.
Weitere Hinweise findet man zum Thema NTP im sehr guten und ausführlichem WIKIPEDIA-Artikel. Eine Gegenüberstellung zu verschiedenen NTP-Implementierungen finden sich auf der folgenden chrony Projektseite Vergleich von NTP-Implementierungen.
In diesem Artikel wollen wir uns eingehender damit beschäftigen, wie wir zum einen mit Unterstützung des Chrony (NTP-Client) mit einem Chrony-Server (NTP-Daemon) synchronisieren können. In beiden Konfigurationsfällen greifen wir auf das Projekt chrony zurück.
Installation
Die einschlägigen Distributionen stellen für das Projekt chrony entsprechende Pakete bereit. Zur Installation bemühen wir den zugehörigen Paketmanager.
Chrony auf einem Fedora/RHEL Basierendem System installieren
Hier verwenden wir in aktuellen Versionen den Paketmanager dnf und in älteren Versionen den Paketmanager yum.
- Als User:
$ sudo ndf install chrony -y
bzw.
$ sudo yum install chrony -y
- Als Nutzer mit Root-Rechten entsprechend:
$ ndf install chrony -y
bzw.
$ yum install chrony -y
Chrony auf einem Debian/Ubuntu Basierendem System installieren
Hier verwenden wir das gewohnte Advanced Packaging Tool apt.
- Als User:
$ sudo apt install chrony -y
- Als Nutzer mit Root-Rechten entsprechend:
$ sudo apt install chrony -y
Chrony auf einem (open)SuSE Basierendem System installieren
Hier verwenden wir das gewohnte Paketmanager Zypper zypper.
- Als User:
$ sudo zypper install chrony -y
- Als Nutzer mit Root-Rechten entsprechend:
$ sudo zypper install chrony -y
Chrony unter Arch Linux installieren
Bei der Installation des chrony-Paketes verwenden wir unter Arch Linux den Paketmanager pacman.
- Als User:
$ sudo pacman -S chrony -y
- Als Nutzer mit Root-Rechten entsprechend:
$ sudo pacman -S chrony -y
Paketinhalt
Was uns das Paket chrony alles in das System unseres Arch Linux Hosts gebracht hat, können wir wie folgt abfragen:
# pacman -Qil chrony
chronyc und chronyd
Nach der Installation des chrony Paketes finden wir zwei Binärpakete in unserem System.
Binary chronyc
chronyc ist das Commandline-Interface des chrony Daemon. chronyc ist ein Kommandozeilen-Interface-Programm, mit dem die Leistung des chronyd überwacht werden und mit dem man bei Bedarf während der Laufzeit verschiedene Betriebsparameter abändern kann.
Die wichtigsten Parameter die beim Aufruf des Befehls mitgegeben werden können, kann man sich mit der Option –help anzeigen lassen.
$ chronyc --help
Usage: chronyc [OPTION]... [COMMAND]...
Options:
-4 Use IPv4 addresses only
-6 Use IPv6 addresses only
-n Don't resolve hostnames
-N Print original source names
-c Enable CSV format
-e End responses with dot
-m Accept multiple commands
-h HOST Specify server (/var/run/chrony/chronyd.sock,127.0.0.1,::1)
-p PORT Specify UDP port (323)
-v, --version Print version and exit
--help Print usage and exit
Manualpage von chronyc
Bei Bedarf wirft man einen Blick in besagte Manual-Page (zum Öffnen der im WIKI abgelegten Man-Page auf die grauen Balken klicken!) :
$ man chronyc
CHRONYC(1) User manual CHRONYC(1)
NAME
chronyc - command-line interface for chrony daemon
SYNOPSIS
chronyc [OPTION]... [COMMAND]...
DESCRIPTION
chronyc is a command-line interface program which can be used to monitor chronyd's performance and to change various
operating parameters whilst it is running.
If no commands are specified on the command line, chronyc will expect input from the user. The prompt chronyc> will be
displayed when it is being run from a terminal. If chronyc's input or output are redirected from or to a file, the
prompt will not be shown.
There are two ways chronyc can access chronyd. One is the Internet Protocol (IPv4 or IPv6) and the other is a Unix
domain socket, which is accessible locally by the root or chrony user. By default, chronyc first tries to connect to
the Unix domain socket. The compiled-in default path is /var/run/chrony/chronyd.sock. If that fails (e.g. because
chronyc is running under a non-root user), it will try to connect to 127.0.0.1 and then ::1.
Only the following monitoring commands, which do not affect the behaviour of chronyd, are allowed from the network:
activity, manual list, rtcdata, smoothing, sourcename, sources, sourcestats, tracking, waitsync. The set of hosts from
which chronyd will accept these commands can be configured with the cmdallow directive in the chronyd's configuration
file or the cmdallow command in chronyc. By default, the commands are accepted only from localhost (127.0.0.1 or ::1).
All other commands are allowed only through the Unix domain socket. When sent over the network, chronyd will respond
with a ‘Not authorised’ error, even if it is from localhost.
Having full access to chronyd via chronyc is more or less equivalent to being able to modify the chronyd's
configuration file and restart it.
OPTIONS
-4
With this option hostnames will be resolved only to IPv4 addresses.
-6
With this option hostnames will be resolved only to IPv6 addresses.
-n
This option disables resolving of IP addresses to hostnames, e.g. to avoid slow DNS lookups. Long addresses will
not be truncated to fit into the column.
-N
This option enables printing of original hostnames or IP addresses of NTP sources that were specified in the
configuration file, or chronyc commands. Without the -n and -N option, the printed hostnames are obtained from
reverse DNS lookups and can be different from the specified hostnames.
-c
This option enables printing of reports in a comma-separated values (CSV) format. Reverse DNS lookups will be
disabled, time will be printed as number of seconds since the epoch, and values in seconds will not be converted to
other units.
-e
With this option each chronyc response will end with a line containing a single dot.
-d
This option enables printing of debugging messages if chronyc was compiled with debugging support.
-m
Normally, all arguments on the command line are interpreted as one command. With this option multiple commands can
be specified. Each argument will be interpreted as a whole command.
-h host
This option specifies the host to be contacted by chronyc. It can be specified with a hostname, IP address, or path
to the local Unix domain socket. Multiple values can be specified as a comma-separated list to provide a fallback.
The default value is /var/run/chrony/chronyd.sock,127.0.0.1,::1, i.e. the host where chronyc is being run. First,
it tries to connect to the Unix domain socket and if that fails (e.g. due to running under a non-root user), it
will try to connect to 127.0.0.1 and then ::1.
-p port
This option allows the user to specify the UDP port number which the target chronyd is using for its monitoring
connections. This defaults to 323; there would rarely be a need to change this.
-f file
This option is ignored and is provided only for compatibility.
-a
This option is ignored and is provided only for compatibility.
-v, --version
With this option chronyc displays its version number on the terminal and exits.
--help
With this option chronyc displays a help message on the terminal and exits.
COMMANDS
This section describes each of the commands available within the chronyc program.
System clock
tracking
The tracking command displays parameters about the system’s clock performance. An example of the output is shown
below.
Reference ID : CB00710F (ntp1.example.net)
Stratum : 3
Ref time (UTC) : Fri Jan 27 09:49:17 2017
System time : 0.000006523 seconds slow of NTP time
Last offset : -0.000006747 seconds
RMS offset : 0.000035822 seconds
Frequency : 3.225 ppm slow
Residual freq : -0.000 ppm
Skew : 0.129 ppm
Root delay : 0.013639022 seconds
Root dispersion : 0.001100737 seconds
Update interval : 64.2 seconds
Leap status : Normal
The fields are explained as follows:
Reference ID
This is the reference ID and name (or IP address) of the server to which the computer is currently
synchronised. For IPv4 addresses, the reference ID is equal to the address and for IPv6 addresses it is the
first 32 bits of the MD5 sum of the address.
If the reference ID is 7F7F0101 and there is no name or IP address, it means the computer is not synchronised
to any external source and that you have the local mode operating (via the local command in chronyc, or the
local directive in the configuration file).
The reference ID is printed as a hexadecimal number. Note that in older versions it used to be printed in
quad-dotted notation and could be confused with an IPv4 address.
Stratum
The stratum indicates how many hops away from a computer with an attached reference clock we are. Such a
computer is a stratum-1 computer, so the computer in the example is two hops away (i.e. ntp1.example.net is a
stratum-2 and is synchronised from a stratum-1).
Ref time
This is the time (UTC) at which the last measurement from the reference source was processed.
System time
This is the current offset between the NTP clock and system clock. The NTP clock is a software (virtual) clock
maintained by chronyd, which is synchronised to the configured time sources and provides time to NTP clients.
The system clock is synchronised to the NTP clock. To avoid steps in the system time, which might have adverse
consequences for certain applications, the system clock is normally corrected only by speeding up or slowing
down (up to the rate configured by the maxslewrate directive). If the offset is too large, this correction will
take a very long time. A step can be forced by the makestep command, or the makestep directive in the
configuration file.
Note that all other offsets reported by chronyc and most offsets in the log files are relative to the NTP
clock, not the system clock.
Last offset
This is the estimated local offset on the last clock update. A positive value indicates the local time (as
previously estimated true time) was ahead of the time sources.
RMS offset
This is a long-term average of the offset value.
Frequency
The ‘frequency’ is the rate by which the system’s clock would be wrong if chronyd was not correcting it. It is
expressed in ppm (parts per million). For example, a value of 1 ppm would mean that when the system’s clock
thinks it has advanced 1 second, it has actually advanced by 1.000001 seconds relative to true time.
Residual freq
This shows the ‘residual frequency’ for the currently selected reference source. This reflects any difference
between what the measurements from the reference source indicate the frequency should be and the frequency
currently being used.
The reason this is not always zero is that a smoothing procedure is applied to the frequency. Each time a
measurement from the reference source is obtained and a new residual frequency computed, the estimated accuracy
of this residual is compared with the estimated accuracy (see ‘skew’ next) of the existing frequency value. A
weighted average is computed for the new frequency, with weights depending on these accuracies. If the
measurements from the reference source follow a consistent trend, the residual will be driven to zero over
time.
Skew
This is the estimated error bound on the frequency.
Root delay
This is the total of the network path delays to the stratum-1 computer from which the computer is ultimately
synchronised.
Root dispersion
This is the total dispersion accumulated through all the computers back to the stratum-1 computer from which
the computer is ultimately synchronised. Dispersion is due to system clock resolution, statistical measurement
variations, etc.
An absolute bound on the computer’s clock accuracy (assuming the stratum-1 computer is correct) is given by:
clock_error <= |system_time_offset| + root_dispersion + (0.5 * root_delay)
Update interval
This is the interval between the last two clock updates.
Leap status
This is the leap status, which can be Normal, Insert second, Delete second or Not synchronised.
makestep, makestep threshold limit
Normally chronyd will cause the system to gradually correct any time offset, by slowing down or speeding up the
clock as required. In certain situations, the system clock might be so far adrift that this slewing process would
take a very long time to correct the system clock.
The makestep command can be used in this situation. There are two forms of the command. The first form has no
parameters. It tells chronyd to cancel any remaining correction that was being slewed and jump the system clock by
the equivalent amount, making it correct immediately.
The second form configures the automatic stepping, similarly to the makestep directive. It has two parameters,
stepping threshold (in seconds) and number of future clock updates for which the threshold will be active. This can
be used with the burst command to quickly make a new measurement and correct the clock by stepping if needed,
without waiting for chronyd to complete the measurement and update the clock.
makestep 0.1 1
burst 1/2
BE WARNED: Certain software will be seriously affected by such jumps in the system time. (That is the reason why
chronyd uses slewing normally.)
maxupdateskew skew-in-ppm
This command has the same effect as the maxupdateskew directive in the configuration file.
waitsync [max-tries [max-correction [max-skew [interval]]]]
The waitsync command waits for chronyd to synchronise.
Up to four optional arguments can be specified. The first is the maximum number of tries before giving up and
returning a non-zero error code. When 0 is specified, or there are no arguments, the number of tries will not be
limited.
The second and third arguments are the maximum allowed remaining correction of the system clock and the maximum
allowed skew (in ppm) as reported by the tracking command in the System time and Skew fields. If not specified or
zero, the value will not be checked.
The fourth argument is the interval specified in seconds in which the check is repeated. The interval is 10 seconds
by default.
An example is:
waitsync 60 0.01
which will wait up to about 10 minutes (60 times 10 seconds) for chronyd to synchronise to a source and the
remaining correction to be less than 10 milliseconds.
Time sources
sources [-a] [-v]
This command displays information about the current time sources that chronyd is accessing.
If the -a option is specified, all sources are displayed, including those that do not have a known address yet.
Such sources have an identifier in the format ID#XXXXXXXXXX, which can be used in other commands expecting a source
address.
The -v option enables a verbose output. In this case, extra caption lines are shown as a reminder of the meanings
of the columns.
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
#* GPS0 0 4 377 11 -479ns[ -621ns] +/- 134ns
^? ntp1.example.net 2 6 377 23 -923us[ -924us] +/- 43ms
^+ ntp2.example.net 1 6 377 21 -2629us[-2619us] +/- 86ms
The columns are as follows:
M
This indicates the mode of the source. ^ means a server, = means a peer and # indicates a locally connected
reference clock.
S
This column indicates the selection state of the source.
• * indicates the best source which is currently selected for synchronisation.
• + indicates other sources selected for synchronisation, which are combined with the best source.
• - indicates a source which is considered to be selectable for synchronisation, but not currently selected.
• x indicates a source which chronyd thinks is a falseticker (i.e. its time is inconsistent with a majority
of other sources, or sources specified with the trust option).
• ~ indicates a source whose time appears to have too much variability.
• ? indicates a source which is not considered to be selectable for synchronisation for other reasons (e.g.
unreachable, not synchronised, or does not have enough measurements).
The selectdata command can be used to get more details about the selection state.
Name/IP address
This shows the name or the IP address of the source, or reference ID for reference clocks.
Stratum
This shows the stratum of the source, as reported in its most recently received sample. Stratum 1 indicates a
computer with a locally attached reference clock. A computer that is synchronised to a stratum 1 computer is at
stratum 2. A computer that is synchronised to a stratum 2 computer is at stratum 3, and so on.
Poll
This shows the rate at which the source is being polled, as a base-2 logarithm of the interval in seconds.
Thus, a value of 6 would indicate that a measurement is being made every 64 seconds. chronyd automatically
varies the polling rate in response to prevailing conditions.
Reach
This shows the source’s reachability register printed as an octal number. The register has 8 bits and is
updated on every received or missed packet from the source. A value of 377 indicates that a valid reply was
received for all from the last eight transmissions.
LastRx
This column shows how long ago the last good sample (which is shown in the next column) was received from the
source. Measurements that failed some tests are ignored. This is normally in seconds. The letters m, h, d or y
indicate minutes, hours, days, or years.
Last sample
This column shows the offset between the local clock and the source at the last measurement. The number in the
square brackets shows the actual measured offset. This can be suffixed by ns (indicating nanoseconds), us
(indicating microseconds), ms (indicating milliseconds), or s (indicating seconds). The number to the left of
the square brackets shows the original measurement, adjusted to allow for any slews applied to the local clock
since. Positive offsets indicate that the local clock is ahead of the source. The number following the +/-
indicator shows the margin of error in the measurement (NTP root distance).
sourcestats [-a] [-v]
The sourcestats command displays information about the drift rate and offset estimation process for each of the
sources currently being examined by chronyd.
If the -a option is specified, all sources are displayed, including those that do not have a known address yet.
Such sources have an identifier in the format ID#XXXXXXXXXX, which can be used in other commands expecting a source
address.
The -v option enables a verbose output. In this case, extra caption lines are shown as a reminder of the meanings
of the columns.
An example report is:
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
===============================================================================
ntp1.example.net 11 5 46m -0.001 0.045 1us 25us
The columns are as follows:
Name/IP Address
This is the name or IP address of the NTP server (or peer) or reference ID of the reference clock to which the
rest of the line relates.
NP
This is the number of sample points currently being retained for the server. The drift rate and current offset
are estimated by performing a linear regression through these points.
NR
This is the number of runs of residuals having the same sign following the last regression. If this number
starts to become too small relative to the number of samples, it indicates that a straight line is no longer a
good fit to the data. If the number of runs is too low, chronyd discards older samples and re-runs the
regression until the number of runs becomes acceptable.
Span
This is the interval between the oldest and newest samples. If no unit is shown the value is in seconds. In the
example, the interval is 46 minutes.
Frequency
This is the estimated residual frequency for the server, in parts per million. In this case, the computer’s
clock is estimated to be running 1 part in 10^9 slow relative to the server.
Freq Skew
This is the estimated error bounds on Freq (again in parts per million).
Offset
This is the estimated offset of the source.
Std Dev
This is the estimated sample standard deviation.
selectdata [-a] [-v]
The selectdata command displays information specific to the selection of time sources. If the -a option is
specified, all sources are displayed, including those that do not have a known address yet. With the -v option,
extra caption lines are shown as a reminder of the meanings of the columns.
An example of the output is shown below.
S Name/IP Address Auth COpts EOpts Last Score Interval Leap
=======================================================================
D ntp1.example.net Y ----- --TR- 4 1.0 -61ms +62ms N
* ntp2.example.net N ----- ----- 0 1.0 -6846us +7305us N
+ ntp3.example.net N ----- ----- 10 1.0 -7381us +7355us N
The columns are as follows:
S
This column indicates the state of the source after the last source selection. It is similar to the state
reported by the sources command, but more states are reported.
The following states indicate the source is not considered selectable for synchronisation:
• N - has the noselect option.
• s - is not synchronised.
• M - does not have enough measurements.
• d - has a root distance larger than the maximum distance (configured by the maxdistance directive).
• ~ - has a jitter larger than the maximum jitter (configured by the maxjitter directive).
• w - waits for other sources to get out of the M state.
• S - has older measurements than other sources.
• O - has a stratum equal or larger than the orphan stratum (configured by the local directive).
• T - does not fully agree with sources that have the trust option.
• x - does not agree with other sources (falseticker).
The following states indicate the source is considered selectable, but it is not currently used for
synchronisation:
• W - waits for other sources to be selectable (required by the minsources directive, or the require option
of another source).
• P - another selectable source is preferred due to the prefer option.
• U - waits for a new measurement (after selecting a different best source).
• D - has, or recently had, a root distance which is too large to be combined with other sources (configured
by the combinelimit directive).
The following states indicate the source is used for synchronisation of the local clock:
• + - combined with the best source.
• * - selected as the best source to update the reference data (e.g. root delay, root dispersion).
Name/IP address
This column shows the name or IP address of the source if it is an NTP server, or the reference ID if it is a
reference clock.
Auth
This column indicites whether an authentication mechanism is enabled for the source. Y means yes and N means
no.
COpts
This column displays the configured selection options of the source.
• N indicates the noselect option.
• P indicates the prefer option.
• T indicates the trust option.
• R indicates the require option.
EOpts
This column displays the current effective selection options of the source, which can be different from the
configured options due to the authentication selection mode (configured by the authselectmode directive). The
symbols are the same as in the COpts column.
Last
This column displays how long ago was the last measurement of the source made when the selection was performed.
Score
This column displays the current score against the source in the * state. The scoring system avoids frequent
reselection when multiple sources have a similar root distance. A value larger than 1 indicates this source was
better than the * source in recent selections. If the score reaches 10, the best source will be reselected and
the scores will be reset to 1.
Interval
This column displays the lower and upper endpoint of the interval which was expected to contain the true offset
of the local clock considering the root distance at the time of the selection.
Leap
This column displays the current leap status of the source.
• N indicates the normal status (no leap second).
• + indicates that a leap second will be inserted at the end of the month.
• - indicates that a leap second will be deleted at the end of the month.
• ? indicates the unknown status (i.e. no valid measurement was made).
selectopts address|refid [+|-option]...
The selectopts command modifies the configured selection options of an NTP source specified by IP address (or the
ID#XXXXXXXXXX identifier used for unknown addresses), or a reference clock specified by reference ID as a string.
The selection options can be added with the + symbol or removed with the - symbol. The selectdata command can be
used to verify the configuration. The modified options will be applied in the next source selection, e.g. when a
new measurement is made, or the reselect command is executed.
An example of using this command is shown below.
selectopts 1.2.3.4 -noselect +prefer
selectopts GPS +trust
reselect
To avoid excessive switching between sources, chronyd can stay synchronised to a source even when it is not
currently the best one among the available sources.
The reselect command can be used to force chronyd to reselect the best synchronisation source.
reselectdist distance
The reselectdist command sets the reselection distance. It is equivalent to the reselectdist directive in the
configuration file.
NTP sources
activity
This command reports the number of servers and peers that are online and offline. If the auto_offline option is
used in specifying some of the servers or peers, the activity command can be useful for detecting when all of them
have entered the offline state after the network link has been disconnected.
The report shows the number of servers and peers in 5 states:
online
the server or peer is currently online (i.e. assumed by chronyd to be reachable)
offline
the server or peer is currently offline (i.e. assumed by chronyd to be unreachable, and no measurements from it
will be attempted.)
burst_online
a burst command has been initiated for the server or peer and is being performed; after the burst is complete,
the server or peer will be returned to the online state.
burst_offline
a burst command has been initiated for the server or peer and is being performed; after the burst is complete,
the server or peer will be returned to the offline state.
unresolved
the name of the server or peer was not resolved to an address yet; this source is not visible in the sources
and sourcestats reports.
authdata [-a]
The authdata command displays information specific to authentication of NTP sources. If the -a option is specified,
all sources are displayed, including those that do not have a known address yet. An example of the output is shown
below.
Name/IP address Mode KeyID Type KLen Last Atmp NAK Cook CLen
=========================================================================
ntp1.example.net NTS 1 15 256 135m 0 0 8 100
ntp2.example.net SK 30 13 128 - 0 0 0 0
ntp3.example.net - 0 0 0 - 0 0 0 0
The columns are as follows:
Name/IP address
This column shows the name or the IP address of the source.
Mode
This column shows which mechanism authenticates NTP packets received from the source. NTS means Network Time
Security, SK means a symmetric key, and - means authentication is disabled.
KeyID
This column shows an identifier of the key used for authentication. With a symmetric key, it is the ID from the
key file. With NTS, it is a number starting at zero and incremented by one with each successful key
establishment using the NTS-KE protocol, i.e. it shows how many times the key establishment was performed with
this source.
Type
This columns shows an identifier of the algorithm used for authentication. With a symmetric key, it is the hash
function or cipher specified in the key file. With NTS, it is an authenticated encryption with associated data
(AEAD) algorithm, which is negotiated in the NTS-KE protocol. The following values can be reported:
• 1: MD5
• 2: SHA1
• 3: SHA256
• 4: SHA384
• 5: SHA512
• 6: SHA3-224
• 7: SHA3-256
• 8: SHA3-384
• 9: SHA3-512
• 10: TIGER
• 11: WHIRLPOOL
• 13: AES128
• 14: AES256
• 15: AEAD-AES-SIV-CMAC-256
• 30: AEAD-AES-128-GCM-SIV
KLen
This column shows the length of the key in bits.
Last
This column shows how long ago the last successful key establishment was performed. It is in seconds, or
letters m, h, d or y indicate minutes, hours, days, or years.
Atmp
This column shows the number of attempts to perform the key establishment since the last successful key
establishment. A number larger than 1 indicates a problem with the network or server.
NAK
This column shows whether an NTS NAK was received since the last request. A NAK indicates that authentication
failed on the server side due to chronyd using a cookie which is no longer valid and that it needs to perform
the key establishment again in order to get new cookies.
Cook
This column shows the number of NTS cookies that chronyd currently has. If the key establishment was
successful, a number smaller than 8 indicates a problem with the network or server.
CLen
This column shows the length in bytes of the NTS cookie which will be used in the next request.
ntpdata [address]
The ntpdata command displays the last valid measurement and other NTP-specific information about the specified NTP
source, or all NTP sources (with a known address) if no address was specified. An example of the output is shown
below.
Remote address : 203.0.113.15 (CB00710F)
Remote port : 123
Local address : 203.0.113.74 (CB00714A)
Leap status : Normal
Version : 4
Mode : Server
Stratum : 1
Poll interval : 10 (1024 seconds)
Precision : -24 (0.000000060 seconds)
Root delay : 0.000015 seconds
Root dispersion : 0.000015 seconds
Reference ID : 47505300 (GPS)
Reference time : Fri Nov 25 15:22:12 2016
Offset : -0.000060878 seconds
Peer delay : 0.000175634 seconds
Peer dispersion : 0.000000681 seconds
Response time : 0.000053050 seconds
Jitter asymmetry: +0.00
NTP tests : 111 111 1111
Interleaved : No
Authenticated : No
TX timestamping : Kernel
RX timestamping : Kernel
Total TX : 24
Total RX : 24
Total valid RX : 24
Total good RX : 22
The fields are explained as follows:
Remote address
The IP address of the NTP server or peer, and the corresponding reference ID.
Remote port
The UDP port number to which the request was sent. The standard NTP port is 123.
Local address
The local IP address which received the response, and the corresponding reference ID.
Leap status, Version, Mode, Stratum, Poll interval, Precision, Root delay, Root dispersion, Reference ID, Reference
time
The NTP values from the last valid response.
Offset, Peer delay, Peer dispersion
The measured values.
Response time
The time the server or peer spent in processing of the request and waiting before sending the response.
Jitter asymmetry
The estimated asymmetry of network jitter on the path to the source. The asymmetry can be between -0.5 and 0.5.
A negative value means the delay of packets sent to the source is more variable than the delay of packets sent
from the source back.
NTP tests
Results of RFC 5905 tests 1 through 3, 5 through 7, and tests for maximum delay, delay ratio, delay dev ratio
(or delay quantile), and synchronisation loop.
Interleaved
This shows if the response was in the interleaved mode.
Authenticated
This shows if the response was authenticated.
TX timestamping
The source of the local transmit timestamp. Valid values are Daemon, Kernel, and Hardware.
RX timestamping
The source of the local receive timestamp.
Total TX
The number of packets sent to the source.
Total RX
The number of all packets received from the source.
Total valid RX
The number of packets which passed the first two groups of NTP tests.
Total good RX
The number of packets which passed all three groups of NTP tests, i.e. the NTP measurement was accepted.
add peer name [option]...
The add peer command allows a new NTP peer to be added whilst chronyd is running.
Following the words add peer, the syntax of the following parameters and options is identical to that for the peer
directive in the configuration file.
An example of using this command is shown below.
add peer ntp1.example.net minpoll 6 maxpoll 10 key 25
add pool name [option]...
The add pool command allows a pool of NTP servers to be added whilst chronyd is running.
Following the words add pool, the syntax of the following parameters and options is identical to that for the pool
directive in the configuration file.
An example of using this command is shown below:
add server name [option]...
The add server command allows a new NTP server to be added whilst chronyd is running.
Following the words add server, the syntax of the following parameters and options is identical to that for the
server directive in the configuration file.
An example of using this command is shown below:
add server ntp1.example.net minpoll 6 maxpoll 10 key 25
delete address
The delete command allows an NTP server or peer to be removed from the current set of sources.
burst good/max [mask/masked-address], burst good/max [masked-address/masked-bits], burst good/max [address]
The burst command tells chronyd to make a set of measurements to each of its NTP sources over a short duration
(rather than the usual periodic measurements that it makes). After such a burst, chronyd will revert to the
previous state for each source. This might be either online, if the source was being periodically measured in the
normal way, or offline, if the source had been indicated as being offline. (A source can be switched between the
online and offline states with the online and offline commands.)
The mask and masked-address arguments are optional, in which case chronyd will initiate a burst for all of its
currently defined sources.
The arguments have the following meaning and format:
good
This defines the number of good measurements that chronyd will want to obtain from each source. A measurement
is good if it passes certain tests, for example, the round trip time to the source must be acceptable. (This
allows chronyd to reject measurements that are likely to be bogus.)
max
This defines the maximum number of measurements that chronyd will attempt to make, even if the required number
of good measurements has not been obtained.
mask
This is an IP address with which the IP address of each of chronyd's sources is to be masked.
masked-address
This is an IP address. If the masked IP address of a source matches this value then the burst command is
applied to that source.
masked-bits
This can be used with masked-address for CIDR notation, which is a shorter alternative to the form with mask.
address
This is an IP address or a hostname. The burst command is applied only to that source.
If no mask or masked-address arguments are provided, every source will be matched.
An example of the two-argument form of the command is:
burst 2/10
This will cause chronyd to attempt to get two good measurements from each source, stopping after two have been
obtained, but in no event will it try more than ten probes to the source.
Examples of the four-argument form of the command are:
burst 2/10 255.255.0.0/1.2.0.0
burst 2/10 2001:db8:789a::/48
1.2.x.y, where x and y are arbitrary. In the second case, the sampling will be applied to sources whose IPv6
addresses have first 48 bits equal to 2001:db8:789a.
Example of the three-argument form of the command is:
burst 2/10 ntp1.example.net
maxdelay address delay
This allows the maxdelay option for one of the sources to be modified, in the same way as specifying the maxdelay
option for the server directive in the configuration file.
maxdelaydevratio address ratio
This allows the maxdelaydevratio option for one of the sources to be modified, in the same way as specifying the
maxdelaydevratio option for the server directive in the configuration file.
maxdelayratio address ratio
This allows the maxdelayratio option for one of the sources to be modified, in the same way as specifying the
maxdelayratio option for the server directive in the configuration file.
maxpoll address maxpoll
The maxpoll command is used to modify the maximum polling interval for one of the current set of sources. It is
equivalent to the maxpoll option in the server directive in the configuration file.
Note that the new maximum polling interval only takes effect after the next measurement has been made.
minpoll address minpoll
The minpoll command is used to modify the minimum polling interval for one of the current set of sources. It is
equivalent to the minpoll option in the server directive in the configuration file.
Note that the new minimum polling interval only takes effect after the next measurement has been made.
minstratum address minstratum
The minstratum command is used to modify the minimum stratum for one of the current set of sources. It is
equivalent to the minstratum option in the server directive in the configuration file.
offline [address], offline [masked-address/masked-bits], offline [mask/masked-address]
The offline command is used to warn chronyd that the network connection to a particular host or hosts is about to
be lost, e.g. on computers with intermittent connection to their time sources.
Another case where offline could be used is where a computer serves time to a local group of computers, and has a
permanent connection to true time servers outside the organisation. However, the external connection is heavily
loaded at certain times of the day and the measurements obtained are less reliable at those times. In this case, it
is probably most useful to determine the gain or loss rate during the quiet periods and let the whole network coast
through the loaded periods. The offline and online commands can be used to achieve this.
There are four forms of the offline command. The first form is a wildcard, meaning all sources (including sources
that do not have a known address yet). The second form allows an IP address mask and a masked address to be
specified. The third form uses CIDR notation. The fourth form uses an IP address or a hostname. These forms are
illustrated below.
offline
offline 255.255.255.0/1.2.3.0
offline 2001:db8:789a::/48
offline ntp1.example.net
The second form means that the offline command is to be applied to any source whose IPv4 address is in the 1.2.3
subnet. (The host’s address is logically and-ed with the mask, and if the result matches the masked-address the
host is processed.) The third form means that the command is to be applied to all sources whose IPv6 addresses have
their first 48 bits equal to 2001:db8:789a. The fourth form means that the command is to be applied only to that
one source.
The wildcard form of the address is equivalent to:
offline 0.0.0.0/0.0.0.0
offline ::/0
online [address], online [masked-address/masked-bits], online [mask/masked-address]
The online command is opposite in function to the offline command. It is used to advise chronyd that network
connectivity to a particular source or sources has been restored.
The syntax is identical to that of the offline command.
onoffline
The onoffline command tells chronyd to switch all sources that have a known address to the online or offline status
according to the current network configuration. A source is considered online if it is possible to send requests to
it, i.e. a network route to the source is present.
polltarget address polltarget
The polltarget command is used to modify the poll target for one of the current set of sources. It is equivalent to
the polltarget option in the server directive in the configuration file.
refresh
The refresh command can be used to force chronyd to resolve the names of configured NTP sources to IP addresses
again and replace any addresses missing in the list of resolved addresses.
Sources that stop responding are replaced with newly resolved addresses automatically after 8 polling intervals.
This command can be used to replace them immediately, e.g. after suspending and resuming the machine in a different
network.
Note that with pools which have more than 16 addresses, or not all IPv4 or IPv6 addresses are included in a single
DNS response (e.g. pool.ntp.org), this command might replace the addresses even if they are still in the pool.
reload sources
The reload sources command causes chronyd to re-read all *.sources files from the directories specified by the
sourcedir directive.
Note that modified sources (e.g. specified with a new option) are not modified in memory. They are removed and
added again, which causes them to lose old measurements and reset the selection state.
sourcename address
The sourcename command prints the original hostname or address that was specified for an NTP source in the
configuration file, or the add command. This command is an alternative to the -N option, which can be useful in
scripts.
Note that different NTP sources can share the same name, e.g. servers from a pool.
Manual time input
manual on, manual off, manual delete index, manual list, manual reset
The manual command enables and disables use of the settime command, and is used to modify the behaviour of the
manual clock driver.
The on form of the command enables use of the settime command.
The off form of the command disables use of the settime command.
The list form of the command lists all the samples currently stored in chronyd. The output is illustrated below.
210 n_samples = 1
# Date Time(UTC) Slewed Original Residual
====================================================
0 27Jan99 22:09:20 0.00 0.97 0.00
The columns are as as follows:
1. The sample index (used for the manual delete command).
2. The date and time of the sample.
3. The system clock error when the timestamp was entered, adjusted to allow for changes made to the system clock
since.
4. The system clock error when the timestamp was entered, as it originally was (without allowing for changes to
the system clock since).
5. The regression residual at this point, in seconds. This allows ‘outliers’ to be easily spotted, so that they
can be deleted using the manual delete command.
The delete form of the command deletes a single sample. The parameter is the index of the sample, as shown in the
first column of the output from manual list. Following deletion of the data point, the current error and drift rate
are re-estimated from the remaining data points and the system clock trimmed if necessary. This option is intended
to allow ‘outliers’ to be discarded, i.e. samples where the administrator realises they have entered a very poor
timestamp.
The reset form of the command deletes all samples at once. The system clock is left running as it was before the
command was entered.
settime time
The settime command allows the current time to be entered manually, if this option has been configured into
chronyd. (It can be configured either with the manual directive in the configuration file, or with the manual
command of chronyc.)
It should be noted that the computer’s sense of time will only be as accurate as the reference you use for
providing this input (e.g. your watch), as well as how well you can time the press of the return key.
Providing your computer’s time zone is set up properly, you will be able to enter a local time (rather than UTC).
The response to a successful settime command indicates the amount that the computer’s clock was wrong. It should be
apparent from this if you have entered the time wrongly, e.g. with the wrong time zone.
The rate of drift of the system clock is estimated by a regression process using the entered measurement and all
previous measurements entered during the present run of chronyd. However, the entered measurement is used for
adjusting the current clock offset (rather than the estimated intercept from the regression, which is ignored).
Contrast what happens with the manual delete command, where the intercept is used to set the current offset (since
there is no measurement that has just been entered in that case).
The time is parsed by the public domain getdate algorithm. Consequently, you can only specify time to the nearest
second.
Examples of inputs that are valid are shown below:
settime 16:30
settime 16:30:05
settime Nov 21, 2015 16:30:05
For a full description of getdate, see the getdate documentation (bundled, for example, with the source for GNU
tar).
NTP access
accheck address
This command allows you to check whether client NTP access is allowed from a particular host.
Examples of use, showing a named host and a numeric IP address, are as follows:
accheck ntp1.example.net
accheck 1.2.3.4
accheck 2001:db8::1
This command can be used to examine the effect of a series of allow, allow all, deny, and deny all commands
specified either via chronyc, or in chronyd's configuration file.
clients [-p packets] [-k] [-r]
This command shows a list of clients that have accessed the server, through the NTP, command, or NTS-KE port. It
does not include accesses over the Unix domain command socket.
The -p option specifies the minimum number of received NTP or command packets, or accepted NTS-KE connections,
needed to include a client in the list. The default value is 0, i.e. all clients are reported. With the -k option
the last four columns will show the NTS-KE accesses instead of command accesses. If the -r option is specified,
chronyd will reset the counters of received and dropped packets or connections after reporting the current values.
An example of the output is:
Hostname NTP Drop Int IntL Last Cmd Drop Int Last
===============================================================================
localhost 2 0 2 - 133 15 0 -1 7
ntp1.example.net 12 0 6 - 23 0 0 - -
Each row shows the data for a single host. Only hosts that have passed the host access checks (set with the allow,
deny, cmdallow and cmddeny commands or configuration file directives) are logged. The intervals are displayed as a
power of 2 in seconds.
The columns are as follows:
1. The hostname of the client.
2. The number of NTP packets received from the client.
3. The number of NTP packets dropped to limit the response rate.
4. The average interval between NTP packets.
5. The average interval between NTP packets after limiting the response rate.
6. Time since the last NTP packet was received
7. The number of command packets or NTS-KE connections received/accepted from the client.
8. The number of command packets or NTS-KE connections dropped to limit the response rate.
9. The average interval between command packets or NTS-KE connections.
10. Time since the last command packet or NTS-KE connection was received/accepted.
serverstats
The serverstats command displays NTP and command server statistics.
An example of the output is shown below.
NTP packets received : 1598
NTP packets dropped : 8
Command packets received : 19
Command packets dropped : 0
Client log records dropped : 0
NTS-KE connections accepted: 3
NTS-KE connections dropped : 0
Authenticated NTP packets : 189
Interleaved NTP packets : 43
NTP timestamps held : 44
NTP timestamp span : 120
NTP daemon RX timestamps : 0
NTP daemon TX timestamps : 1537
NTP kernel RX timestamps : 1590
NTP kernel TX timestamps : 43
NTP hardware RX timestamps : 0
NTP hardware TX timestamps : 0
The fields have the following meaning:
NTP packets received
The number of valid NTP requests received by the server.
NTP packets dropped
The number of NTP requests dropped by the server due to rate limiting (configured by the ratelimit directive).
Command packets received
The number of command requests received by the server.
Command packets dropped
The number of command requests dropped by the server due to rate limiting (configured by the cmdratelimit
directive).
Client log records dropped
The number of client log records dropped by the server to limit the memory use (configured by the
clientloglimit directive).
NTS-KE connections accepted
The number of NTS-KE connections accepted by the server.
NTS-KE connections dropped
The number of NTS-KE connections dropped by the server due to rate limiting (configured by the ntsratelimit
directive).
Authenticated NTP packets
The number of received NTP requests that were authenticated (with a symmetric key or NTS).
Interleaved NTP packets
The number of received NTP requests that were detected to be in the interleaved mode.
NTP timestamps held
The number of pairs of receive and transmit timestamps that the server is currently holding in memory for
clients using the interleaved mode.
NTP timestamp span
The interval (in seconds) covered by the currently held NTP timestamps.
NTP daemon RX timestamps
The number of NTP responses which included a receive timestamp captured by the daemon.
NTP daemon TX timestamps
The number of NTP responses which included a transmit timestamp captured by the daemon.
NTP kernel RX timestamps
The number of NTP responses which included a receive timestamp captured by the kernel.
NTP kernel TX timestamps
The number of NTP responses (in the interleaved mode) which included a transmit timestamp captured by the
kernel.
NTP hardware RX timestamps
The number of NTP responses which included a receive timestamp captured by the NIC.
NTP hardware TX timestamps
The number of NTP responses (in the interleaved mode) which included a transmit timestamp captured by the NIC.
allow [all] [subnet]
The effect of the allow command is identical to the allow directive in the configuration file.
The syntax is illustrated in the following examples:
allow 1.2.3.4
allow all 3.4.5.0/24
allow 2001:db8:789a::/48
allow 0/0
allow ::/0
allow
allow all
deny [all] [subnet]
The effect of the allow command is identical to the deny directive in the configuration file.
The syntax is illustrated in the following examples:
deny 1.2.3.4
deny all 3.4.5.0/24
deny 2001:db8:789a::/48
deny 0/0
deny ::/0
deny
deny all
local [option]..., local off
The local command allows chronyd to be told that it is to appear as a reference source, even if it is not itself
properly synchronised to an external source. This can be used on isolated networks, to allow a computer to be the
primary time server for other computers.
The first form enables the local reference mode on the host. The syntax is identical to the local directive in the
configuration file.
The second form disables the local reference mode.
smoothing
The smoothing command displays the current state of the NTP server time smoothing, which can be enabled with the
smoothtime directive. An example of the output is shown below.
Active : Yes
Offset : +1.000268817 seconds
Frequency : -0.142859 ppm
Wander : -0.010000 ppm per second
Last update : 17.8 seconds ago
Remaining time : 19988.4 seconds
The fields are explained as follows:
Active
This shows if the server time smoothing is currently active. Possible values are Yes and No. If the leaponly
option is included in the smoothtime directive, (leap second only) will be shown on the line.
Offset
This is the current offset applied to the time sent to NTP clients. Positive value means the clients are
getting time that’s ahead of true time.
Frequency
The current frequency offset of the served time. Negative value means the time observed by clients is running
slower than true time.
Wander
The current frequency wander of the served time. Negative value means the time observed by clients is slowing
down.
Last update
This field shows how long ago the time smoothing process was updated, e.g. chronyd accumulated a new
measurement.
Remaining time
The time it would take for the smoothing process to get to zero offset and frequency if there were no more
updates.
smoothtime activate, smoothtime reset
The smoothtime command can be used to activate or reset the server time smoothing process if it is configured with
the smoothtime directive.
Monitoring access
cmdaccheck address
This command is similar to the accheck command, except that it is used to check whether monitoring access is
permitted from a named host.
Examples of use are as follows:
cmdaccheck ntp1.example.net
cmdaccheck 1.2.3.4
cmdaccheck 2001:db8::1
cmdallow [all] [subnet]
This is similar to the allow command, except that it is used to allow particular hosts or subnets to use chronyc to
monitor with chronyd on the current host.
cmddeny [all] [subnet]
This is similar to the deny command, except that it is used to allow particular hosts or subnets to use chronyc to
monitor chronyd on the current host.
Real-time clock (RTC)
rtcdata
The rtcdata command displays the current RTC parameters.
An example output is shown below.
RTC ref time (GMT) : Sat May 30 07:25:56 2015
Number of samples : 10
Number of runs : 5
Sample span period : 549
RTC is fast by : -1.632736 seconds
RTC gains time at : -107.623 ppm
The fields have the following meaning:
RTC ref time (GMT)
This is the RTC reading the last time its error was measured.
Number of samples
This is the number of previous measurements being used to determine the RTC gain or loss rate.
Number of runs
This is the number of runs of residuals of the same sign following the regression fit for (RTC error) versus
(RTC time). A value which is small indicates that the measurements are not well approximated by a linear model,
and that the algorithm will tend to delete the older measurements to improve the fit.
Sample span period
This is the period that the measurements span (from the oldest to the newest). Without a unit the value is in
seconds; suffixes m for minutes, h for hours, d for days or y for years can be used.
RTC is fast by
This is the estimate of how many seconds fast the RTC when it thought the time was at the reference time
(above). If this value is large, you might (or might not) want to use the trimrtc command to bring the RTC into
line with the system clock. (Note, a large error will not affect chronyd's operation, unless it becomes so big
as to start causing rounding errors.)
RTC gains time at
This is the amount of time gained (positive) or lost (negative) by the real time clock for each second that it
ticks. It is measured in parts per million. So if the value shown was +1, suppose the RTC was exactly right
when it crosses a particular second boundary. Then it would be 1 microsecond fast when it crosses its next
second boundary.
trimrtc
The trimrtc command is used to correct the system’s real-time clock (RTC) to the main system clock. It has no
effect if the error between the two clocks is currently estimated at less than a second.
The command takes no arguments. It performs the following steps (if the RTC is more than 1 second away from the
system clock):
1. Remember the currently estimated gain or loss rate of the RTC and flush the previous measurements.
2. Step the real-time clock to bring it within a second of the system clock.
3. Make several measurements to accurately determine the new offset between the RTC and the system clock (i.e. the
remaining fraction of a second error).
4. Save the RTC parameters to the RTC file (specified with the rtcfile directive in the configuration file).
The last step is done as a precaution against the computer suffering a power failure before either the daemon exits
or the writertc command is issued.
chronyd will still work perfectly well both whilst operating and across machine reboots even if the trimrtc command
is never used (and the RTC is allowed to drift away from true time). The trimrtc command is provided as a method by
which it can be corrected, in a manner compatible with chronyd using it to maintain accurate time across machine
reboots.
The trimrtc command can be executed automatically by chronyd with the rtcautotrim directive in the configuration
file.
writertc
The writertc command writes the currently estimated error and gain or loss rate parameters for the RTC to the RTC
file (specified with the rtcfile directive). This information is also written automatically when chronyd is killed
(by the SIGHUP, SIGINT, SIGQUIT or SIGTERM signals) or when the trimrtc command is issued.
Other daemon commands
cyclelogs
The cyclelogs command causes all of chronyd's open log files to be closed and re-opened. This allows them to be
renamed so that they can be periodically purged. An example of how to do this is shown below.
# mv /var/log/chrony/measurements.log /var/log/chrony/measurements1.log
# chronyc cyclelogs
# rm /var/log/chrony/measurements1.log
dump
The dump command causes chronyd to write its current history of measurements for each of its sources to dump files
in the directory specified in the configuration file by the dumpdir directive and also write server NTS keys and
client NTS cookies to the directory specified by the ntsdumpdir directive. Note that chronyd does this
automatically when it exits. This command is mainly useful for inspection whilst chronyd is running.
rekey
The rekey command causes chronyd to re-read the key file specified in the configuration file by the keyfile
directive. It also re-reads the server NTS keys if ntsdumpdir is specified and automatic rotation is disabled in
the configuration file.
reset sources
The reset sources command causes chronyd to drop all measurements and switch to the unsynchronised state. This
command can help chronyd with recovery when the measurements are known to be no longer valid or accurate, e.g. due
to moving the computer to a different network, or resuming the computer from a low-power state (which resets the
system clock). chronyd will drop the measurements automatically when it detects the clock has made an unexpected
jump, but the detection is not completely reliable.
shutdown
The shutdown command causes chronyd to exit. This is equivalent to sending the process the SIGTERM signal.
Client commands
dns option
The dns command configures how hostnames and IP addresses are resolved in chronyc. IP addresses can be resolved to
hostnames when printing results of sources, sourcestats, tracking and clients commands. Hostnames are resolved in
commands that take an address as argument.
There are five options:
dns -n
Disables resolving IP addresses to hostnames. Raw IP addresses will be displayed.
dns +n
Enables resolving IP addresses to hostnames. This is the default unless chronyc was started with -n option.
dns -4
Resolves hostnames only to IPv4 addresses.
dns -6
Resolves hostnames only to IPv6 addresses.
dns -46
Resolves hostnames to both address families. This is the default behaviour unless chronyc was started with the
-4 or -6 option.
timeout timeout
The timeout command sets the initial timeout for chronyc requests in milliseconds. If no response is received from
chronyd, the timeout is doubled and the request is resent. The maximum number of retries is configured with the
retries command.
By default, the timeout is 1000 milliseconds.
retries retries
The retries command sets the maximum number of retries for chronyc requests before giving up. The response timeout
is controlled by the timeout command.
The default is 2.
keygen [id [type [bits]]]
The keygen command generates a key that can be added to the key file (specified with the keyfile directive) to
allow NTP authentication between server and client, or peers. The key is generated from the /dev/urandom device and
it is printed to standard output.
The command has three optional arguments. The first argument is the key number (by default 1), which will be
specified with the key option of the server or peer directives in the configuration file. The second argument is
the name of the hash function or cipher (by default SHA1, or MD5 if SHA1 is not available). The third argument is
the length of the key in bits if a hash function was selected, between 80 and 4096 bits (by default 160 bits).
An example is:
keygen 73 SHA1 256
which generates a 256-bit SHA1 key with number 73. The printed line should then be securely transferred and added
to the key files on both server and client, or peers. A different key should be generated for each client or peer.
An example using the AES128 cipher is:
keygen 151 AES128
exit, quit
The exit and quit commands exit from chronyc and return the user to the shell.
help
The help command displays a summary of the commands and their arguments.
dns +n
Enables resolving IP addresses to hostnames. This is the default unless chronyc was started with -n option.
dns -4
Resolves hostnames only to IPv4 addresses.
dns -6
Resolves hostnames only to IPv6 addresses.
dns -46
Resolves hostnames to both address families. This is the default behaviour unless chronyc was started with the
-4 or -6 option.
timeout timeout
The timeout command sets the initial timeout for chronyc requests in milliseconds. If no response is received from
chronyd, the timeout is doubled and the request is resent. The maximum number of retries is configured with the
retries command.
By default, the timeout is 1000 milliseconds.
retries retries
The retries command sets the maximum number of retries for chronyc requests before giving up. The response timeout
is controlled by the timeout command.
The default is 2.
keygen [id [type [bits]]]
The keygen command generates a key that can be added to the key file (specified with the keyfile directive) to
allow NTP authentication between server and client, or peers. The key is generated from the /dev/urandom device and
it is printed to standard output.
The command has three optional arguments. The first argument is the key number (by default 1), which will be
specified with the key option of the server or peer directives in the configuration file. The second argument is
the name of the hash function or cipher (by default SHA1, or MD5 if SHA1 is not available). The third argument is
the length of the key in bits if a hash function was selected, between 80 and 4096 bits (by default 160 bits).
An example is:
keygen 73 SHA1 256
which generates a 256-bit SHA1 key with number 73. The printed line should then be securely transferred and added
to the key files on both server and client, or peers. A different key should be generated for each client or peer.
An example using the AES128 cipher is:
keygen 151 AES128
exit, quit
The exit and quit commands exit from chronyc and return the user to the shell.
help
The help command displays a summary of the commands and their arguments.
SEE ALSO
chrony.conf(5), chronyd(8)
BUGS
For instructions on how to report bugs, please visit https://chrony-project.org/.
AUTHORS
chrony was written by Richard Curnow, Miroslav Lichvar, and others.
chrony 4.5 2023-12-05 CHRONYC(1)
Binary chronyd
chronyd ist der Daemon von chrony der dasfür sorgt, dass der chrony-Dienst während des Neustarts gestartet und somit aktiviert wird.
Wie schon beim Commandline-Interface chronyc können wir uns auch hier die wichtigsten Optionen die beim Aufruf des Befehls mitgegeben werden können mit der Option –help zur Anzeige gebracht werden.
$ chronyd --help
Usage: chronyd [OPTION]... [DIRECTIVE]... Options: -4 Use IPv4 addresses only -6 Use IPv6 addresses only -f FILE Specify configuration file (/etc/chrony.conf) -n Don't run as daemon -d Don't run as daemon and log to stderr -l FILE Log to file -L LEVEL Set logging threshold (0) -p Print configuration and exit -q Set clock and exit -Q Log offset and exit -r Reload dump files -R Adapt configuration for restart -s Set clock from RTC -t SECONDS Exit after elapsed time -u USER Specify user (chrony) -U Don't check for root -F LEVEL Set system call filter level (0) -P PRIORITY Set process priority (0) -m Lock memory -x Don't control clock -v, --version Print version and exit -h, --help Print usage and exit
Manualpage von chronyd
Eine ausführliche Beschreibung des Daemon und seiner Optionen findet man in zugehöriger Manual-Page (zum Öffnen der im WIKI abgelegten Man-Page auf die grauen Balken klicken!) :
$ man chronyd
Dokumentation
Eine ausführliche Onlinedokumentation des Chrony Projekts findet sich auf der entsprechnden Projektseite → https://chrony-project.org/documentation.html Bei der Installation des aktuellen chrony-Paketes z.B. unter Arch Linux finden sich im Verzeichnis /usr/share/doc/chrony/ auch entsprechende FAQs, READMEs, NEWS und Beispiele.
# tree /usr/share/doc/chrony/
/usr/share/doc/chrony// ├── examples/ │ ├── chrony.conf.example1 │ ├── chrony.conf.example2 │ ├── chrony.conf.example3 │ ├── chronyd-restricted.service │ ├── chronyd.service │ ├── chrony.keys.example │ ├── chrony.logrotate │ ├── chrony.nm-dispatcher.dhcp │ ├── chrony.nm-dispatcher.onoffline │ └── chrony-wait.service ├── chronyc.html ├── chrony.conf.html ├── chronyd.html ├── FAQ ├── faq.html ├── installation.html ├── NEWS └── README
FAQ
Zum Öffnen der im WIKI abgelegten FAQ-Page auf die grauen Balken klicken!
$ less /usr/share/doc/chrony/FAQ
Frequently Asked Questions
Table of Contents
o 1. chrony compared to other programs
? 1.1. How does chrony compare to ntpd?
? 1.2. Should I prefer chrony over timesyncd if I do not need to run a
server?
o 2. Configuration issues
? 2.1. What is the minimum recommended configuration for an NTP client?
? 2.2. How do I make an NTP server?
? 2.3. Should all computers on a LAN be clients of an external server?
? 2.4. Must I specify servers by IP address if DNS is not available on
chronyd start?
? 2.5. How can I make chronyd more secure?
? 2.6. How can I make the system clock more secure?
? 2.7. How can I improve the accuracy of the system clock with NTP
sources?
? 2.8. Does chronyd have an ntpdate mode?
? 2.9. Can chronyd be configured to control the clock like ntpd?
? 2.10. Can NTP server be separated from NTP client?
? 2.11. How can chronyd be configured to minimise downtime during
restarts?
? 2.12. Should be a leap smear enabled on NTP server?
? 2.13. How should chronyd be configured with gpsd?
? 2.14. Does chrony support PTP?
? 2.15. How can I avoid using wrong PHC refclock?
? 2.16. Why are client log records dropped before reaching
clientloglimit?
? 2.17. What happened to the commandkey and generatecommandkey
directives?
o 3. Computer is not synchronising
? 3.1. Behind a firewall?
? 3.2. Are NTP servers specified with the offline option?
? 3.3. Is name resolution working correctly?
? 3.4. Is chronyd allowed to step the system clock?
? 3.5. Using NTS?
? 3.6. Using a Windows NTP server?
? 3.7. An unreachable source is selected?
? 3.8. Does selected source drop new measurements?
? 3.9. Using a PPS reference clock?
o 4. Issues with chronyc
? 4.1. I keep getting the error 506 Cannot talk to daemon
? 4.2. I keep getting the error 501 Not authorised
? 4.3. What is the reference ID reported by the tracking command?
? 4.4. Is the chronyc / chronyd protocol documented anywhere?
o 5. Real-time clock issues
? 5.1. What is the real-time clock (RTC)?
? 5.2. Does hwclock have to be disabled?
? 5.3. I just keep getting the 513 RTC driver not running message
? 5.4. I get Could not open /dev/rtc, Device or resource busy in my
syslog file
? 5.5. When I start chronyd, the log says Could not enable RTC interrupt
: Invalid argument (or it may say disable)
? 5.6. What if my computer does not have an RTC or backup battery?
o 6. NTP-specific issues
? 6.1. Can chronyd be driven from broadcast/multicast NTP servers?
? 6.2. Can chronyd transmit broadcast NTP packets?
? 6.3. Can chronyd keep the system clock a fixed offset away from real
time?
? 6.4. What happens if the network connection is dropped without using
chronyc's offline command first?
? 6.5. Why is an offset measured between two computers synchronised to
each another?
o 7. Operation
? 7.1. What clocks does chronyd use?
o 8. Operating systems
? 8.1. Does chrony support Windows?
? 8.2. Are there any plans to support Windows?
1. chrony compared to other programs
1.1. How does chrony compare to ntpd?
chrony and ntpd are two different implementations of the Network Time Protocol
(NTP).
chrony is a newer implementation, which was designed to work well in a wider
range of conditions. It can usually synchronise the system clock faster and
with better time accuracy. It has many features, but it does not implement some
of the less useful NTP modes like broadcast client or multicast server/client.
If your computer is connected to the Internet only for few minutes at a time,
the network connection is often congested, you turn your computer off or
suspend it frequently, the clock is not very stable (e.g. there are rapid
changes in the temperature or it is a virtual machine), or you want to use NTP
on an isolated network with no hardware reference clocks in sight, chrony will
probably work better for you.
For a more detailed comparison of features and performance, see the comparison
page on the chrony website.
1.2. Should I prefer chrony over timesyncd if I do not need to run a server?
Generally, yes.
systemd-timesyncd is a very simple NTP client included in the systemd suite. It
lacks almost all features of chrony and other advanced client implementations
listed on the comparison page. One of its main limitations is that it cannot
poll multiple servers at the same time and detect servers having incorrect time
(falsetickers in the NTP terminology). It should be used only with trusted
reliable servers, ideally in local network.
Using timesyncd with pool.ntp.org is problematic. The pool is very robust as a
whole, but the individual servers run by volunteers cannot be relied on.
Occasionally, servers drift away or make a step to distant past or future due
to misconfiguration, problematic implementation, and other bugs (e.g. in
firmware of a GPS receiver). The pool monitoring system detects such servers
and quickly removes them from the pool DNS, but clients like timesyncd cannot
recover from that. They follow the server as long as it claims to be
synchronised. They need to be restarted in order to get a new address from the
pool DNS.
Note that the complexity of NTP and clock synchronisation is on the client
side. The amount of code in chrony specific to NTP server is very small and it
is disabled by default. If it was removed, it would not significantly reduce
the amount of memory or storage needed.
2. Configuration issues
2.1. What is the minimum recommended configuration for an NTP client?
First, the client needs to know which NTP servers it should ask for the current
time. They are specified by the server or pool directive. The pool directive is
used with names that resolve to multiple addresses of different servers. For
reliable operation, the client should have at least three servers.
The iburst option enables a burst of requests to speed up the initial
synchronisation.
To stabilise the initial synchronisation on the next start, the estimated drift
of the system clock is saved to a file specified by the driftfile directive.
If the system clock can be far from the true time after boot for any reason,
chronyd should be allowed to correct it quickly by stepping instead of slewing,
which would take a very long time. The makestep directive does that.
In order to keep the real-time clock (RTC) close to the true time, so the
system time is reasonably close to the true time when it is initialised on the
next boot from the RTC, the rtcsync directive enables a mode in which the
system time is periodically copied to the RTC. It is supported on Linux and
macOS.
If you wanted to use public NTP servers from the pool.ntp.org project, the
minimal chrony.conf file could be:
pool pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1 3
rtcsync
2.2. How do I make an NTP server?
By default, chronyd does not operate as an NTP server. You need to add an allow
directive to the chrony.conf file in order for chronyd to open the server NTP
port and respond to client requests.
allow 192.168.1.0/24
An allow directive with no specified subnet allows access from all IPv4 and
IPv6 addresses.
2.3. Should all computers on a LAN be clients of an external server?
It depends on the requirements. Usually, the best configuration is to make one
computer the server, with the others as clients of it. Add a local directive to
the server's chrony.conf file. This configuration will be better because
o the load on the external connection is less
o the load on the external NTP server(s) is less
o if your external connection goes down, the computers on the LAN will
maintain a common time with each other.
2.4. Must I specify servers by IP address if DNS is not available on chronyd
start?
No, chronyd will keep trying to resolve the names specified by the server,
pool, and peer directives in an increasing interval until it succeeds. The
online command can be issued from chronyc to force chronyd to try to resolve
the names immediately.
2.5. How can I make chronyd more secure?
If you do not need to use chronyc, or you want to run chronyc only under the
root or chrony user (which can access chronyd through a Unix domain socket),
you can disable the IPv4 and IPv6 command sockets (by default listening on
localhost) by adding cmdport 0 to the configuration file.
You can specify an unprivileged user with the -u option, or the user directive
in the chrony.conf file, to which chronyd will switch after start in order to
drop root privileges. The configure script has a --with-user option, which sets
the default user. On Linux, chronyd needs to be compiled with support for the
libcap library. On other systems, chronyd forks into two processes. The child
process retains root privileges, but can only perform a very limited range of
privileged system calls on behalf of the parent.
Also, if chronyd is compiled with support for the Linux secure computing
(seccomp) facility, you can enable a system call filter with the -F option. It
will significantly reduce the kernel attack surface and possibly prevent kernel
exploits from the chronyd process if it is compromised. It is recommended to
enable the filter only when it is known to work on the version of the system
where chrony is installed as the filter needs to allow also system calls made
from libraries that chronyd is using (e.g. libc) and different versions or
implementations of the libraries might make different system calls. If the
filter is missing some system call, chronyd could be killed even in normal
operation.
2.6. How can I make the system clock more secure?
An NTP client synchronising the system clock to an NTP server is susceptible to
various attacks, which can break applications and network protocols relying on
accuracy of the clock (e.g. DNSSEC, Kerberos, TLS, WireGuard).
Generally, a man-in-the-middle (MITM) attacker between the client and server
can
o make fake responses, or modify real responses from the server, to create an
arbitrarily large time and frequency offset, make the server appear more
accurate, insert a leap second, etc.
o delay the requests and/or responses to create a limited time offset and
temporarily also a limited frequency offset
o drop the requests or responses to prevent updates of the clock with new
measurements
o redirect the requests to a different server
The attacks can be combined for a greater effect. The attacker can delay
packets to create a significant frequency offset first and then drop all
subsequent packets to let the clock quickly drift away from the true time. The
attacker might also be able to control the server's clock.
Some attacks cannot be prevented. Monitoring is needed for detection, e.g. the
reachability register in the sources report shows missing packets. The extent
to which the attacker can control the client's clock depends on its
configuration.
Enable authentication to prevent chronyd from accepting modified, fake, or
redirected packets. It can be enabled with a symmetric key specified by the key
option, or Network Time Security (NTS) by the nts option (supported since
chrony version 4.0). The server needs to support the selected authentication
mechanism. Symmetric keys have to be configured on both client and server, and
each client must have its own key (one per server).
The maximum offset that the attacker can insert in an NTP measurement by
delaying packets can be limited by the maxdelay option. The default value is 3
seconds. The measured delay is reported as the peer delay in the ntpdata report
and measurements log. Set the maxdelay option to a value larger than the
maximum value that is normally observed. Note that the delay can increase
significantly even when not under an attack, e.g. when the network is congested
or the routing has changed.
The maximum accepted change in time offset between clock updates can be limited
by the maxchange directive. Larger changes in the offset will be ignored or
cause chronyd to exit. Note that the attacker can get around this limit by
splitting the offset into multiple smaller offsets and/or creating a large
frequency offset. When this directive is used, chronyd will have to be
restarted after a successful attack. It will not be able to recover on its own.
It must not be restarted automatically (e.g. by the service manager).
The impact of a large accepted time offset can be reduced by disabling clock
steps, i.e. by not using the makestep and initstepslew directives. The offset
will be slowly corrected by speeding up or slowing down the clock at a rate
which can be limited by the maxslewrate directive. Disabling clock steps
completely is practical only if the clock cannot gain a larger error on its
own, e.g. when the computer is shut down or suspended, and the maxslewrate
limit is large enough to correct an expected error in an acceptable time. The
rtcfile directive with the -s option can be used to compensate for the RTC
drift.
A more practical approach is to enable makestep for a limited number of clock
updates (the 2nd argument of the directive) and limit the offset change in all
updates by the maxchange directive. The attacker will be able to make only a
limited step and only if the attack starts in a short window after booting the
computer, or when chronyd is restarted without the -R option.
The frequency offset can be limited by the maxdrift directive. The measured
frequency offset is reported in the drift file, tracking report, and tracking
log. Set maxdrift to a value larger than the maximum absolute value that is
normally observed. Note that the frequency of the clock can change due to aging
of the crystal, differences in calibration of the clock source between reboots,
migrated virtual machine, etc. A typical computer clock has a drift smaller
than 100 parts per million (ppm), but much larger drifts are possible (e.g. in
some virtual machines).
Use only trusted servers, which you expect to be well configured and managed,
using authentication for their own servers, etc. Use multiple servers, ideally
in different locations. The attacker will have to deal with a majority of the
servers in order to pass the source selection and update the clock with a large
offset. Use the minsources directive to increase the required number of
selectable sources to make the selection more robust.
Do not specify servers as peers. The symmetric mode is less secure than the
client/server mode. If not authenticated, it is vulnerable to off-path
denial-of-service attacks, and even when it is authenticated, it is still
susceptible to replay attacks.
Mixing of authenticated and unauthenticated servers should generally be
avoided. If mixing is necessary (e.g. for a more accurate and stable
synchronisation to a closer server which does not support authentication), the
authenticated servers should be configured as trusted and required to not allow
the unauthenticated servers to override the authenticated servers in the source
selection. Since chrony version 4.0, the selection options are enabled in such
a case automatically. This behaviour can be disabled or modified by the
authselectmode directive.
An example of a client configuration limiting the impact of the attacks could
be
server ntp1.example.net iburst nts maxdelay 0.1
server ntp2.example.net iburst nts maxdelay 0.2
server ntp3.example.net iburst nts maxdelay 0.05
server ntp4.example.net iburst nts maxdelay 0.1
server ntp5.example.net iburst nts maxdelay 0.1
minsources 3
maxchange 100 0 0
makestep 0.001 1
maxdrift 100
maxslewrate 100
driftfile /var/lib/chrony/drift
ntsdumpdir /var/lib/chrony
rtcsync
2.7. How can I improve the accuracy of the system clock with NTP sources?
Select NTP servers that are well synchronised, stable and close to your
network. It is better to use more than one server. Three or four is usually
recommended as the minimum, so chronyd can detect servers that serve false time
and combine measurements from multiple sources.
If you have a network card with hardware timestamping supported on Linux, it
can be enabled by the hwtimestamp directive. It should make local receive and
transmit timestamps of NTP packets much more stable and accurate.
The server directive has some useful options: minpoll, maxpoll, polltarget,
maxdelay, maxdelayratio, maxdelaydevratio, xleave, filter.
The first three options set the minimum and maximum allowed polling interval,
and how should be the actual interval adjusted in the specified range. Their
default values are 6 (64 seconds) for minpoll, 10 (1024 seconds) for maxpoll
and 8 (samples) for polltarget. The default values should be used for general
servers on the Internet. With your own NTP servers, or if you have permission
to poll some servers more frequently, setting these options for shorter polling
intervals might significantly improve the accuracy of the system clock.
The optimal polling interval depends mainly on two factors, stability of the
network latency and stability of the system clock (which mainly depends on the
temperature sensitivity of the crystal oscillator and the maximum rate of the
temperature change).
Generally, if the sourcestats command usually reports a small number of samples
retained for a source (e.g. fewer than 16), a shorter polling interval should
be considered. If the number of samples is usually at the maximum of 64, a
longer polling interval might work better.
An example of the directive for an NTP server on the Internet that you are
allowed to poll frequently could be
server ntp.example.net minpoll 4 maxpoll 6 polltarget 16
An example using shorter polling intervals with a server located in the same
LAN could be
server ntp.local minpoll 2 maxpoll 4 polltarget 30
The maxdelay options are useful to ignore measurements with an unusually large
delay (e.g. due to congestion in the network) and improve the stability of the
synchronisation. The maxdelaydevratio option could be added to the example with
local NTP server
server ntp.local minpoll 2 maxpoll 4 polltarget 30 maxdelaydevratio 2
If your server supports the interleaved mode (e.g. it is running chronyd), the
xleave option should be added to the server directive to enable the server to
provide the client with more accurate transmit timestamps (kernel or preferably
hardware). For example:
server ntp.local minpoll 2 maxpoll 4 xleave
When combined with local hardware timestamping, good network switches, and even
shorter polling intervals, a sub-microsecond accuracy and stability of a few
tens of nanoseconds might be possible. For example:
server ntp.local minpoll 0 maxpoll 0 xleave
hwtimestamp eth0
For best stability, the CPU should be running at a constant frequency (i.e.
disabled power saving and performance boosting). Energy-Efficient Ethernet
(EEE) should be disabled in the network. The switches should be configured to
prioritize NTP packets, especially if the network is expected to be heavily
loaded. The dscp directive can be used to set the Differentiated Services Code
Point in transmitted NTP packets if needed.
If it is acceptable for NTP clients in the network to send requests at a high
rate, a sub-second polling interval can be specified. A median filter can be
enabled in order to update the clock at a reduced rate with more stable
measurements. For example:
server ntp.local minpoll -6 maxpoll -6 filter 15 xleave
hwtimestamp eth0 minpoll -6
Since chrony version 4.3, the minimum minpoll is -7 and a filter using a
long-term estimate of a delay quantile can be enabled by the maxdelayquant
option to replace the default maxdelaydevratio filter, which is sensitive to
outliers corrupting the minimum delay. For example:
server ntp.local minpoll -7 maxpoll -7 filter 31 maxdelayquant 0.3 xleave
Since version 4.2, chronyd supports an NTPv4 extension field containing an
additional timestamp to enable frequency transfer and significantly improve
stability of synchronisation. It can be enabled by the extfield F323 option.
For example:
server ntp.local minpoll 0 maxpoll 0 xleave extfield F323
Since version 4.5, chronyd can apply corrections from PTP one-step end-to-end
transparent clocks (e.g. network switches) to significantly improve accuracy of
synchronisation in local networks. It requires the PTP transport to be enabled
by the ptpport directive, HW timestamping, and the extfield F324 option. For
example:
server ntp.local minpoll -4 maxpoll -4 xleave extfield F323 extfield F324 port 319
ptpport 319
hwtimestamp eth0 minpoll -4
2.8. Does chronyd have an ntpdate mode?
Yes. With the -q option chronyd will set the system clock once and exit. With
the -Q option it will print the measured offset without setting the clock. If
you do not want to use a configuration file, NTP servers can be specified on
the command line. For example:
# chronyd -q 'pool pool.ntp.org iburst'
The command above would normally take about 5 seconds if the servers were well
synchronised and responding to all requests. If not synchronised or responding,
it would take about 10 seconds for chronyd to give up and exit with a non-zero
status. A faster configuration is possible. A single server can be used instead
of four servers, the number of measurements can be reduced with the maxsamples
option to one (supported since chrony version 4.0), and a timeout can be
specified with the -t option. The following command would take only up to about
one second.
# chronyd -q -t 1 'server pool.ntp.org iburst maxsamples 1'
It is not recommended to run chronyd with the -q option periodically (e.g. from
a cron job) as a replacement for the daemon mode, because it performs
significantly worse (e.g. the clock is stepped and its frequency is not
corrected). If you must run it this way and you are using a public NTP server,
make sure chronyd does not always start around the first second of a minute,
e.g. by adding a random sleep before the chronyd command. Public servers
typically receive large bursts of requests around the first second as there is
a large number of NTP clients started from cron with no delay.
2.9. Can chronyd be configured to control the clock like ntpd?
It is not possible to perfectly emulate ntpd, but there are some options that
can configure chronyd to behave more like ntpd if there is a reason to prefer
that.
In the following example the minsamples directive slows down the response to
changes in the frequency and offset of the clock. The maxslewrate and
corrtimeratio directives reduce the maximum frequency error due to an offset
correction and the maxdrift directive reduces the maximum assumed frequency
error of the clock. The makestep directive enables a step threshold and the
maxchange directive enables a panic threshold. The maxclockerror directive
increases the minimum dispersion rate.
minsamples 32
maxslewrate 500
corrtimeratio 100
maxdrift 500
makestep 0.128 -1
maxchange 1000 1 1
maxclockerror 15
Note that increasing minsamples might cause the offsets in the tracking and
sourcestats reports/logs to be significantly smaller than the actual offsets
and be unsuitable for monitoring.
2.10. Can NTP server be separated from NTP client?
Yes, it is possible to run multiple instances of chronyd on a computer at the
same time. One can operate primarily as an NTP client to synchronise the system
clock and another as a server for other computers. If they use the same
filesystem, they need to be configured with different pidfiles, Unix domain
command sockets, and any other file or directory specified in the configuration
file. If they run in the same network namespace, they need to use different NTP
and command ports, or bind the ports to different addresses or interfaces.
The server instance should be started with the -x option to prevent it from
adjusting the system clock and interfering with the client instance. It can be
configured as a client to synchronise its NTP clock to other servers, or the
client instance running on the same computer. In the latter case, the copy
option (added in chrony version 4.1) can be used to assume the reference ID and
stratum of the client instance, which enables detection of synchronisation
loops with its own clients.
On Linux, starting with chrony version 4.0, it is possible to run multiple
server instances sharing a port to better utilise multiple cores of the CPU.
Note that for rate limiting and client/server interleaved mode to work well it
is necessary that all packets received from the same address are handled by the
same server instance.
An example configuration of the client instance could be
pool pool.ntp.org iburst
allow 127.0.0.1
port 11123
driftfile /var/lib/chrony/drift
makestep 1 3
rtcsync
and configuration of the first server instance could be
server 127.0.0.1 port 11123 minpoll 0 maxpoll 0 copy
allow
cmdport 11323
bindcmdaddress /var/run/chrony/chronyd-server1.sock
pidfile /var/run/chronyd-server1.pid
driftfile /var/lib/chrony/drift-server1
2.11. How can chronyd be configured to minimise downtime during restarts?
The dumpdir directive in chrony.conf provides chronyd a location to save a
measurement history of the sources it uses when the service exits. The -r
option then enables chronyd to load state from the dump files, reducing the
synchronisation time after a restart.
Similarly, the ntsdumpdir directive provides a location for chronyd to save NTS
cookies received from the server to avoid making a NTS-KE request when chronyd
is started. When operating as an NTS server, chronyd also saves cookies keys to
this directory to allow clients to continue to use the old keys after a server
restart for a more seamless experience.
On Linux systems, systemd socket activation provides a mechanism to reuse
server sockets across chronyd restarts, so that client requests will be
buffered until the service is again able to handle the requests. This allows
for zero-downtime service restarts, simplified dependency logic at boot, and
on-demand service spawning (for instance, for separated server chronyd
instances run with the -x flag).
Socket activation is supported since chrony version 4.5. The service manager
(systemd) creates sockets and passes file descriptors to them to the process
via the LISTEN_FDS environment variable. Before opening new sockets, chronyd
first checks for and attempts to reuse matching sockets passed from the service
manager. For instance, if an IPv4 datagram socket bound on bindaddress and port
is available, it will be used by the NTP server to accept incoming IPv4
requests.
An example systemd socket unit is below, where chronyd is configured with
bindaddress 0.0.0.0, bindaddress ::, port 123, and ntsport 4460.
[Unit]
Description=chronyd server sockets
[Socket]
Service=chronyd.service
# IPv4 NTP server
ListenDatagram=0.0.0.0:123
# IPv6 NTP server
ListenDatagram=[::]:123
# IPv4 NTS-KE server
ListenStream=0.0.0.0:4460
# IPv6 NTS-KE server
ListenStream=[::]:4460
BindIPv6Only=ipv6-only
[Install]
WantedBy=sockets.target
2.12. Should be a leap smear enabled on NTP server?
With the smoothtime and leapsecmode directives it is possible to enable a
server leap smear in order to hide leap seconds from clients and force them to
follow a slow server's adjustment instead.
This feature should be used only in local networks and only when necessary,
e.g. when the clients cannot be configured to handle the leap seconds as
needed, or their number is so large that configuring them all would be
impractical. The clients should use only one leap-smearing server, or multiple
identically configured leap-smearing servers. Note that some clients can get
leap seconds from other sources (e.g. with the leapsectz directive in chrony)
and they will not work correctly with a leap smearing server.
2.13. How should chronyd be configured with gpsd?
A GPS or other GNSS receiver can be used as a reference clock with gpsd. It can
work as one or two separate time sources for each connected receiver. The first
time source is based on timestamping of messages sent by the receiver.
Typically, it is accurate to milliseconds. The other source is much more
accurate. It is timestamping a pulse-per-second (PPS) signal, usually connected
to a serial port (e.g. DCD pin) or GPIO pin.
If the PPS signal is connected to the serial port which is receiving messages
from the GPS/GNSS receiver, gpsd should detect and use it automatically. If it
is connected to a GPIO pin, or another serial port, the PPS device needs to be
specified on the command line as an additional data source. On Linux, the
ldattach utility can be used to create a PPS device for a serial device.
The PPS-based time source provided by gpsd is available as a SHM 1 refclock, or
other odd number if gpsd is configured with multiple receivers, and also as
SOCK /var/run/chrony.DEV.sock where DEV is the name of the serial device (e.g.
ttyS0).
The message-based time source is available as a SHM 0 refclock (or other even
number) and since gpsd version 3.25 also as SOCK /var/run/chrony.clk.DEV.sock
where DEV is the name of the serial device.
The SOCK refclocks should be preferred over SHM for better security (the shared
memory segment needs to be created by chronyd or gpsd with an expected owner
and permissions before an untrusted application or user has a chance to create
its own in order to feed chronyd with false measurements). gpsd needs to be
started after chronyd in order to connect to the socket.
With chronyd and gpsd both supporting PPS, there are two different recommended
configurations:
# First option
refclock SOCK /var/run/chrony.ttyS0.sock refid GPS
# Second option
refclock PPS /dev/pps0 lock NMEA refid GPS
refclock SOCK /var/run/chrony.clk.ttyS0.sock offset 0.5 delay 0.1 refid NMEA noselect
They both have some advantages:
o SOCK can be more accurate than PPS if gpsd corrects for the sawtooth error
provided by the receiver in serial data
o PPS can be used with higher PPS rates (specified by the rate option), but
it requires a second refclock or another time source to pair pulses with
seconds, and the SOCK offset needs to be specified correctly to compensate
for the message delay, while gpsd can apply HW-specific information
If the PPS signal is not available, or cannot be used for some reason, the only
option is the message-based timing
refclock SOCK /var/run/chrony.clk.ttyS0.sock offset 0.5 delay 0.1 refid GPS
or the SHM equivalent if using gpsd version before 3.25
refclock SHM 0 offset 0.5 delay 0.1 refid GPS
2.14. Does chrony support PTP?
No, the Precision Time Protocol (PTP) is not supported as a protocol for
synchronisation of clocks and there are no plans to support it. It is a complex
protocol, which shares some issues with the NTP broadcast mode. One of the main
differences between NTP and PTP is that PTP was designed to be easily supported
in hardware (e.g. network switches and routers) in order to make more stable
and accurate measurements. PTP relies on the hardware support. NTP does not
rely on any support in the hardware, but if it had the same support as PTP, it
could perform equally well.
On Linux, chrony supports hardware clocks that some NICs have for PTP. They are
called PTP hardware clocks (PHC). They can be used as reference clocks
(specified by the refclock directive) and for hardware timestamping of NTP
packets (enabled by the hwtimestamp directive) if the NIC can timestamp other
packets than PTP, which is usually the case at least for transmitted packets.
The ethtool -T command can be used to verify the timestamping support.
As an experimental feature added in version 4.2, chrony can use PTP as a
transport for NTP messages (NTP over PTP) to enable hardware timestamping on
hardware which can timestamp PTP packets only. It can be enabled by the ptpport
directive. Since version 4.5, chrony can also apply corrections provided by PTP
one-step end-to-end transparent clocks to reach the accuracy of ordinary PTP
clocks. The application of PTP corrections can be enabled by the extfield F324
option.
2.15. How can I avoid using wrong PHC refclock?
If your system has multiple PHC devices, normally named by udev as /dev/ptp0, /
dev/ptp1, and so on, their order can change randomly across reboots depending
on the order of initialisation of their drivers. If a PHC refclock is specified
by this name, chronyd could be using a wrong refclock after reboot. To prevent
that, you can configure udev to create a stable symlink for chronyd with a rule
like this (e.g. written to /etc/udev/rules.d/80-phc.rules):
KERNEL=="ptp[0-9]*", DEVPATH=="/devices/pci0000:00/0000:00:01.2/0000:02:00.0/ptp/*", SYMLINK+="ptp-i350-1"
You can get the full DEVPATH of an existing PHC device with the udevadm info
command. You will need to execute the udevadm trigger command, or reboot the
system, for these changes to take effect.
2.16. Why are client log records dropped before reaching clientloglimit?
The number of dropped client log records reported by the serverstats command
can be increasing before the number of clients reported by the clients command
reaches the maximum value corresponding to the memory limit set by the
clientloglimit directive.
This is due to the design of the data structure keeping the client records. It
is a hash table which can store only up to 16 colliding addresses per slot. If
a slot has more collisions and the table already has the maximum size, the
oldest record will be dropped and replaced by the new client.
Note that the size of the table is always a power of two and it can only grow.
The limit set by the clientloglimit directive takes into account that two
copies of the table exist when it is being resized. This means the actual
memory usage reported by top and other utilities can be significantly smaller
than the limit even when the maximum number of records is used.
The absolute maximum number of client records kept at the same time is
16777216.
2.17. What happened to the commandkey and generatecommandkey directives?
They were removed in version 2.2. Authentication is no longer supported in the
command protocol. Commands that required authentication are now allowed only
through a Unix domain socket, which is accessible only by the root and chrony
users. If you need to configure chronyd remotely or locally without the root
password, please consider using ssh and/or sudo to run chronyc under the root
or chrony user on the host where chronyd is running.
3. Computer is not synchronising
This is the most common problem. There are a number of reasons, see the
following questions.
3.1. Behind a firewall?
Check the Reach value printed by the chronyc's sources command. If it is zero,
it means chronyd did not get any valid responses from the NTP server you are
trying to use. If there is a firewall between you and the server, the requests
sent to the UDP port 123 of the server or responses sent back from the port
might be blocked. Try using a tool like wireshark or tcpdump to see if you are
getting any responses from the server.
When chronyd is receiving responses from the servers, the output of the sources
command issued few minutes after chronyd start might look like this:
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp1.example.net 2 6 377 34 +484us[ -157us] +/- 30ms
^- ntp2.example.net 2 6 377 34 +33ms[ +32ms] +/- 47ms
^+ ntp3.example.net 3 6 377 35 -1397us[-2033us] +/- 60ms
3.2. Are NTP servers specified with the offline option?
Check that the chronyc's online and offline commands are used appropriately
(e.g. in the system networking scripts). The activity command prints the number
of sources that are currently online and offline. For example:
200 OK
3 sources online
0 sources offline
0 sources doing burst (return to online)
0 sources doing burst (return to offline)
0 sources with unknown address
3.3. Is name resolution working correctly?
NTP servers specified by their hostname (instead of an IP address) have to have
their names resolved before chronyd can send any requests to them. If the
activity command prints a non-zero number of sources with unknown address,
there is an issue with the resolution. Typically, a DNS server is specified in
/etc/resolv.conf. Make sure it is working correctly.
Since chrony version 4.0, you can run chronyc -N sources -a command to print
all sources, even those that do not have a known address yet, with their names
as they were specified in the configuration. This can be useful to verify that
the names specified in the configuration are used as expected.
3.4. Is chronyd allowed to step the system clock?
By default, chronyd adjusts the clock gradually by slowing it down or speeding
it up. If the clock is too far from the true time, it will take a long time to
correct the error. The System time value printed by the chronyc's tracking
command is the remaining correction that needs to be applied to the system
clock.
The makestep directive can be used to allow chronyd to step the clock. For
example, if chrony.conf had
makestep 1 3
the clock would be stepped in the first three updates if its offset was larger
than one second. Normally, it is recommended to allow the step only in the
first few updates, but in some cases (e.g. a computer without an RTC or virtual
machine which can be suspended and resumed with an incorrect time) it might be
necessary to allow the step on any clock update. The example above would change
to
makestep 1 -1
3.5. Using NTS?
The Network Time Security (NTS) mechanism uses Transport Layer Security (TLS)
to establish the keys needed for authentication of NTP packets.
Run the authdata command to check whether the key establishment was successful:
# chronyc -N authdata
Name/IP address Mode KeyID Type KLen Last Atmp NAK Cook CLen
=========================================================================
ntp1.example.net NTS 1 15 256 33m 0 0 8 100
ntp2.example.net NTS 1 15 256 33m 0 0 8 100
ntp3.example.net NTS 1 15 256 33m 0 0 8 100
The KeyID, Type, and KLen columns should have non-zero values. If they are
zero, check the system log for error messages from chronyd. One possible cause
of failure is a firewall blocking the client's connection to the server's TCP
port 4460.
Another possible cause of failure is a certificate that is failing to verify
because the client's clock is wrong. This is a chicken-and-egg problem with
NTS. You might need to manually correct the date, or temporarily disable NTS,
in order to get NTS working. If your computer has an RTC and it is backed up by
a good battery, this operation should be needed only once, assuming the RTC
will be set periodically with the rtcsync directive, or compensated with the
rtcfile directive and the -s option.
If the computer does not have an RTC or battery, you can use the -s option
without rtcfile directive to restore time of the last shutdown or reboot from
the drift file. The clock will start behind the true time, but if the computer
was not shut down for too long and the server's certificate was not renewed too
close to its expiration, it should be sufficient for the time checks to
succeed.
If you run your own server, you can use a self-signed certificate covering all
dates where the client can start (e.g. years 1970-2100). The certificate needs
to be installed on the client and specified with the ntstrustedcerts directive.
The server can have multiple names and certificates. To avoid trusting a
certificate for too long, a new certificate can be added to the server
periodically (e.g. once per year) and the client can have the server name and
trusted certificate updated automatically (e.g. using a package repository, or
a cron script downloading the files directly from the server over HTTPS). A
client that was shut down for years will still be able to synchronise its clock
and perform the update as long as the server keeps the old certificate.
As a last resort, you can disable the time checks by the nocerttimecheck
directive. This has some important security implications. To reduce the
security risk, you can use the nosystemcert and ntstrustedcerts directives to
disable the system's default trusted certificate authorities and trust only a
minimal set of selected authorities needed to validate the certificates of used
NTP servers.
3.6. Using a Windows NTP server?
A common issue with Windows NTP servers is that they report a very large root
dispersion (e.g. three seconds or more), which causes chronyd to ignore the
server for being too inaccurate. The sources command might show a valid
measurement, but the server is not selected for synchronisation. You can check
the root dispersion of the server with the chronyc's ntpdata command.
The maxdistance value needs to be increased in chrony.conf to enable
synchronisation to such a server. For example:
maxdistance 16.0
3.7. An unreachable source is selected?
When chronyd is configured with multiple time sources, it tries to select the
most accurate and stable sources for synchronisation of the system clock. They
are marked with the * or + symbol in the report printed by the sources command.
When the best source (marked with the * symbol) becomes unreachable (e.g. NTP
server stops responding), chronyd will not immediately switch to the second
best source in an attempt to minimise the error of the clock. It will let the
clock run free for as long as its estimated error (in terms of root distance)
based on previous measurements is smaller than the estimated error of the
second source, and there is still an interval which contains some measurements
from both sources.
If the first source was significantly better than the second source, it can
take many hours before the second source is selected, depending on its polling
interval. You can force a faster reselection by increasing the clock error rate
(maxclockerror directive), shortening the polling interval (maxpoll option), or
reducing the number of samples (maxsamples option).
3.8. Does selected source drop new measurements?
chronyd can drop a large number of successive NTP measurements if they are not
passing some of the NTP tests. The sources command can report for a selected
source the fully-reachable value of 377 in the Reach column and at the same
time a LastRx value that is much larger than the current polling interval. If
the source is online, this indicates that a number of measurements was dropped.
You can use the ntpdata command to check the NTP tests for the last
measurement. Usually, it is the test C which fails.
This can be an issue when there is a long-lasting increase in the measured
delay, e.g. due to a routing change in the network. Unfortunately, chronyd does
not know for how long it should wait for the delay to come back to the original
values, or whether it is a permanent increase and it should start from scratch.
The test C is an adaptive filter. It can take many hours before it accepts a
measurement with the larger delay, and even much longer before it drops all
measurements with smaller delay, which determine an expected delay used by the
test. You can use the reset sources command to drop all measurements
immediately (available in chrony 4.0 and later). If this issue happens
frequently, you can effectively disable the test by setting the
maxdelaydevratio option to a very large value (e.g. 1000000), or speed up the
recovery by increasing the clock error rate with the maxclockerror directive.
3.9. Using a PPS reference clock?
A pulse-per-second (PPS) reference clock requires a non-PPS time source to
determine which second of UTC corresponds to each pulse. If it is another
reference clock specified with the lock option in the refclock directive, the
offset between the two reference clocks must be smaller than 0.4 seconds (0.2
seconds with chrony versions before 4.1) in order for the PPS reference clock
to work. With NMEA reference clocks it is common to have a larger offset. It
needs to be corrected with the offset option.
One approach to find out a good value of the offset option is to configure the
reference clocks with the noselect option and compare them to an NTP server.
For example, if the sourcestats command showed
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
PPS0 0 0 0 +0.000 2000.000 +0ns 4000ms
NMEA 58 30 231 -96.494 38.406 +504ms 6080us
ntp1.example.net 7 3 200 -2.991 16.141 -107us 492us
the offset of the NMEA source would need to be increased by about 0.504
seconds. It does not have to be very accurate. As long as the offset of the
NMEA reference clock stays below the limit, the PPS reference clock should be
able to determine the seconds corresponding to the pulses and allow the samples
to be used for synchronisation.
4. Issues with chronyc
4.1. I keep getting the error 506 Cannot talk to daemon
When accessing chronyd remotely, make sure that the chrony.conf file (on the
computer where chronyd is running) has a cmdallow entry for the computer you
are running chronyc on and an appropriate bindcmdaddress directive. This is not
necessary for localhost.
Perhaps chronyd is not running. Try using the ps command (e.g. on Linux, ps
-auxw) to see if it is running. Or try netstat -a and see if the UDP port 323
is listening. If chronyd is not running, you might have a problem with the way
you are trying to start it (e.g. at boot time).
Perhaps you have a firewall set up in a way that blocks packets on the UDP port
323. You need to amend the firewall configuration in this case.
4.2. I keep getting the error 501 Not authorised
This error indicates that chronyc sent the command to chronyd using a UDP
socket instead of the Unix domain socket (e.g. /var/run/chrony/chronyd.sock),
which is required for some commands. For security reasons, only the root and
chrony users are allowed to access the socket.
It is also possible that the socket does not exist. chronyd will not create the
socket if the directory has a wrong owner or permissions. In this case there
should be an error message from chronyd in the system log.
4.3. What is the reference ID reported by the tracking command?
The reference ID is a 32-bit value used in NTP to prevent synchronisation
loops.
In chrony versions before 3.0 it was printed in the quad-dotted notation, even
if the reference source did not actually have an IPv4 address. For IPv4
addresses, the reference ID is equal to the address, but for IPv6 addresses it
is the first 32 bits of the MD5 sum of the address. For reference clocks, the
reference ID is the value specified with the refid option in the refclock
directive.
Since version 3.0, the reference ID is printed as a hexadecimal number to avoid
confusion with IPv4 addresses.
If you need to get the IP address of the current reference source, use the -n
option to disable resolving of IP addresses and read the second field (printed
in parentheses) on the Reference ID line.
4.4. Is the chronyc / chronyd protocol documented anywhere?
Only by the source code. See cmdmon.c (chronyd side) and client.c (chronyc
side).
Note that this protocol is not compatible with the mode 6 or mode 7 protocol
supported by ntpd, i.e. the ntpq or ntpdc utility cannot be used to monitor
chronyd, and chronyc cannot be used to monitor ntpd.
5. Real-time clock issues
5.1. What is the real-time clock (RTC)?
This is the clock which keeps the time even when your computer is turned off.
It is used to initialise the system clock on boot. It normally does not drift
more than few seconds per day.
There are two approaches how chronyd can work with it. One is to use the
rtcsync directive, which tells chronyd to enable a kernel mode which sets the
RTC from the system clock every 11 minutes. chronyd itself will not touch the
RTC. If the computer is not turned off for a long time, the RTC should still be
close to the true time when the system clock will be initialised from it on the
next boot.
The other option is to use the rtcfile directive, which tells chronyd to
monitor the rate at which the RTC gains or loses time. When chronyd is started
with the -s option on the next boot, it will set the system time from the RTC
and also compensate for the drift it has measured previously. The rtcautotrim
directive can be used to keep the RTC close to the true time, but it is not
strictly necessary if its only purpose is to set the system clock when chronyd
is started on boot. See the documentation for details.
5.2. Does hwclock have to be disabled?
The hwclock program is run by default in the boot and/or shutdown scripts in
some Linux installations. With the kernel RTC synchronisation (rtcsync
directive), the RTC will be set also every 11 minutes as long as the system
clock is synchronised. If you want to use chronyd's RTC monitoring (rtcfile
directive), it is important to disable hwclock in the shutdown procedure. If
you do not do that, it will overwrite the RTC with a new value, unknown to
chronyd. At the next reboot, chronyd started with the -s option will compensate
this (wrong) time with its estimate of how far the RTC has drifted whilst the
power was off, giving a meaningless initial system time.
There is no need to remove hwclock from the boot process, as long as chronyd is
started after it has run.
5.3. I just keep getting the 513 RTC driver not running message
For the real-time clock support to work, you need the following three things
o an RTC in your computer
o a Linux kernel with enabled RTC support
o an rtcfile directive in your chrony.conf file
5.4. I get Could not open /dev/rtc, Device or resource busy in my syslog file
Some other program running on the system might be using the device.
5.5. When I start chronyd, the log says Could not enable RTC interrupt :
Invalid argument (or it may say disable)
Your real-time clock hardware might not support the required ioctl requests:
o RTC_UIE_ON
o RTC_UIE_OFF
A possible solution could be to build the Linux kernel with support for
software emulation instead; try enabling the following configuration option
when building the Linux kernel:
o CONFIG_RTC_INTF_DEV_UIE_EMUL
5.6. What if my computer does not have an RTC or backup battery?
In this case you can still use the -s option to set the system clock to the
last modification time of the drift file, which should correspond to the system
time when chronyd was previously stopped. The initial system time will be
increasing across reboots and applications started after chronyd will not
observe backward steps.
6. NTP-specific issues
6.1. Can chronyd be driven from broadcast/multicast NTP servers?
No, the broadcast/multicast client mode is not supported and there is currently
no plan to implement it. While this mode can simplify configuration of clients
in large networks, it is inherently less accurate and less secure (even with
authentication) than the ordinary client/server mode.
When configuring a large number of clients in a network, it is recommended to
use the pool directive with a DNS name which resolves to addresses of multiple
NTP servers. The clients will automatically replace the servers when they
become unreachable, or otherwise unsuitable for synchronisation, with new
servers from the pool.
Even with very modest hardware, an NTP server can serve time to hundreds of
thousands of clients using the ordinary client/server mode.
6.2. Can chronyd transmit broadcast NTP packets?
Yes, the broadcast directive can be used to enable the broadcast server mode to
serve time to clients in the network which support the broadcast client mode
(it is not supported in chronyd). Note that this mode should generally be
avoided. See the previous question.
6.3. Can chronyd keep the system clock a fixed offset away from real time?
Yes. Starting from version 3.0, an offset can be specified by the offset option
for all time sources in the chrony.conf file.
6.4. What happens if the network connection is dropped without using chronyc's
offline command first?
chronyd will keep trying to access the sources that it thinks are online, and
it will take longer before new measurements are actually made and the clock is
corrected when the network is connected again. If the sources were set to
offline, chronyd would make new measurements immediately after issuing the
online command.
Unless the network connection lasts only few minutes (less than the maximum
polling interval), the delay is usually not a problem, and it might be
acceptable to keep all sources online all the time.
6.5. Why is an offset measured between two computers synchronised to each
another?
When two computers are synchronised to each other using the client/server or
symmetric NTP mode, there is an expectation that NTP measurements between the
two computers made on both ends show an average offset close to zero.
With chronyd that can be expected only when the interleaved mode is enabled by
the xleave option. Otherwise, chronyd will use different transmit timestamps
(e.g. daemon timestamp vs kernel timestamp) for serving time and
synchronisation of its own clock, which will cause the other computer to
measure a significant offset.
7. Operation
7.1. What clocks does chronyd use?
There are several different clocks used by chronyd:
o System clock: software clock maintained by the kernel. It is the main clock
used by applications running on the computer. It is synchronised by chronyd
to its NTP clock, unless started with the -x option.
o NTP clock: software clock (virtual) based on the system clock and internal
to chronyd. It keeps the best estimate of the true time according to the
configured time sources, which is served to NTP clients unless time
smoothing is enabled by the smoothtime directive. The System time value in
the tracking report is the current offset between the system and NTP clock.
o Real-time clock (RTC): hardware clock keeping time even when the computer
is turned off. It is used by the kernel to initialise the system clock on
boot and also by chronyd to compensate for its measured drift if configured
with the rtcfile directive and started with the -s option. The clock can be
kept accurate only by stepping enabled by the rtcsync or rtcautotrim
directive.
o Reference clock: hardware clock used as a time source. It is specified by
the refclock directive.
o NIC clock (also known as PTP hardware clock): hardware clock timestamping
packets received and transmitted by a network device specified by the
hwtimestamp directive. The clock is expected to be running free. It is not
synchronised by chronyd. Its offset is tracked relative to the NTP clock in
order to convert the hardware timestamps.
8. Operating systems
8.1. Does chrony support Windows?
No. The chronyc program (the command-line client used for configuring chronyd
while it is running) has been successfully built and run under Cygwin in the
past. chronyd is not portable, because part of it is very system-dependent. It
needs adapting to work with Windows' equivalent of the adjtimex() call, and it
needs to be made to work as a service.
8.2. Are there any plans to support Windows?
We have no plans to do this. Anyone is welcome to pick this work up and
contribute it back to the project.
Last updated 2023-12-05 14:22:10 +0100
NEWS
Zum Öffnen der im WIKI abgelegten NEWS-Page auf die grauen Balken klicken!
$ less /usr/share/doc/chrony/NEWS
New in version 4.5 ================== Enhancements ------------ * Add support for AES-GCM-SIV in GnuTLS * Add support for corrections from PTP transparent clocks * Add support for systemd socket activation Bug fixes --------- * Fix presend in interleaved mode * Fix reloading of modified sources from sourcedir New in version 4.4 ================== Enhancements ------------ * Add support for AES-GCM-SIV with Nettle >= 3.9 to shorten NTS cookies to avoid some length-specific blocking of NTP on Internet * Add support for multiple refclocks using extpps option on one PHC * Add maxpoll option to hwtimestamp directive to improve PHC tracking with low packet rates * Add hwtstimeout directive to configure timeout for late timestamps * Handle late hardware transmit timestamps of NTP requests on all sockets * Handle mismatched 32/64-bit time_t in SOCK refclock samples * Improve source replacement * Log important changes made by command requests (chronyc) * Refresh address of NTP sources periodically * Request nanosecond kernel RX timestamping on FreeBSD * Set DSCP for IPv6 packets * Shorten NTS-KE retry interval when network is down * Update seccomp filter for musl * Warn if loading keys from file with unexpected permissions * Warn if source selection fails or falseticker is detected * Add selectopts command to modify source-specific selection options * Add timestamp sources to serverstats report and make its fields 64-bit * Add -e option to chronyc to indicate end of response New in version 4.3 ================== Enhancements ------------ * Add local option to refclock directive to stabilise system clock with more stable free-running clock (e.g. TCXO, OCXO) * Add maxdelayquant option to server/pool/peer directive to replace maxdelaydevratio filter with long-term quantile-based filtering * Add selection option to log directive * Allow external PPS in PHC refclock without configurable pin * Don't accept first interleaved response to minimise error in delay * Don't use arc4random on Linux to avoid server performance loss * Improve filter option to better handle missing NTP samples * Improve stability with hardware timestamping and PHC refclock * Update seccomp filter Bug fixes --------- * Fix waitsync command to reconnect when not getting response New in version 4.2 ================== Enhancements ------------ * Add support for NTPv4 extension field improving synchronisation stability and resolution of root delay and dispersion (experimental) * Add support for NTP over PTP (experimental) * Add support for AES-CMAC and hash functions in GnuTLS * Improve server interleaved mode to be more reliable and support multiple clients behind NAT * Update seccomp filter * Add statistics about interleaved mode to serverstats report Bug fixes --------- * Fix RTC support with 64-bit time_t on 32-bit Linux * Fix seccomp filter to work correctly with bind*device directives * Suppress kernel adjustments of system clock (dosynctodr) on illumos Other changes ------------- * Switch Solaris support to illumos New in version 4.1 ================== Enhancements ------------ * Add support for NTS servers specified by IP address (matching Subject Alternative Name in server certificate) * Add source-specific configuration of trusted certificates * Allow multiple files and directories with trusted certificates * Allow multiple pairs of server keys and certificates * Add copy option to server/pool directive * Increase PPS lock limit to 40% of pulse interval * Perform source selection immediately after loading dump files * Reload dump files for addresses negotiated by NTS-KE server * Update seccomp filter and add less restrictive level * Restart ongoing name resolution on online command Bug fixes --------- * Fix responding to IPv4 command requests on FreeBSD * Fix dump files to not include uncorrected offset * Fix initstepslew to accept time from own NTP clients * Reset NTP address and port when no longer negotiated by NTS-KE server New in version 4.0 ================== Enhancements ------------ * Add support for Network Time Security (NTS) authentication * Add support for AES-CMAC keys (AES128, AES256) with Nettle * Add authselectmode directive to control selection of unauthenticated sources * Add binddevice, bindacqdevice, bindcmddevice directives * Add confdir directive to better support fragmented configuration * Add sourcedir directive and "reload sources" command to support dynamic NTP sources specified in files * Add clockprecision directive * Add dscp directive to set Differentiated Services Code Point (DSCP) * Add -L option to limit log messages by severity * Add -p option to print whole configuration with included files * Add -U option to allow start under non-root user * Allow maxsamples to be set to 1 for faster update with -q/-Q option * Avoid replacing NTP sources with sources that have unreachable address * Improve pools to repeat name resolution to get "maxsources" sources * Improve source selection with trusted sources * Improve NTP loop test to prevent synchronisation to itself * Repeat iburst when NTP source is switched from offline state to online * Update clock synchronisation status and leap status more frequently * Update seccomp filter * Add "add pool" command * Add "reset sources" command to drop all measurements * Add authdata command to print details about NTP authentication * Add selectdata command to print details about source selection * Add -N option and sourcename command to print original names of sources * Add -a option to some commands to print also unresolved sources * Add -k, -p, -r options to clients command to select, limit, reset data Bug fixes --------- * Don't set interface for NTP responses to allow asymmetric routing * Handle RTCs that don't support interrupts * Respond to command requests with correct address on multihomed hosts Removed features ---------------- * Drop support for RIPEMD keys (RMD128, RMD160, RMD256, RMD320) * Drop support for long (non-standard) MACs in NTPv4 packets (chrony 2.x clients using non-MD5/SHA1 keys need to use option "version 3") * Drop support for line editing with GNU Readline New in version 3.5.1 ==================== Security fixes -------------- * Create new file when writing pidfile (CVE-2020-14367) New in version 3.5 ================== Enhancements ------------ * Add support for more accurate reading of PHC on Linux 5.0 * Add support for hardware timestamping on interfaces with read-only timestamping configuration * Add support for memory locking and real-time priority on FreeBSD, NetBSD, Solaris * Update seccomp filter to work on more architectures * Validate refclock driver options Bug fixes --------- * Fix bindaddress directive on FreeBSD * Fix transposition of hardware RX timestamp on Linux 4.13 and later * Fix building on non-glibc systems New in version 3.4 ================== Enhancements ------------ * Add filter option to server/pool/peer directive * Add minsamples and maxsamples options to hwtimestamp directive * Add support for faster frequency adjustments in Linux 4.19 * Change default pidfile to /var/run/chrony/chronyd.pid to allow chronyd without root privileges to remove it on exit * Disable sub-second polling intervals for distant NTP sources * Extend range of supported sub-second polling intervals * Get/set IPv4 destination/source address of NTP packets on FreeBSD * Make burst options and command useful with short polling intervals * Modify auto_offline option to activate when sending request failed * Respond from interface that received NTP request if possible * Add onoffline command to switch between online and offline state according to current system network configuration * Improve example NetworkManager dispatcher script Bug fixes --------- * Avoid waiting in Linux getrandom system call * Fix PPS support on FreeBSD and NetBSD New in version 3.3 ================== Enhancements ------------ * Add burst option to server/pool directive * Add stratum and tai options to refclock directive * Add support for Nettle crypto library * Add workaround for missing kernel receive timestamps on Linux * Wait for late hardware transmit timestamps * Improve source selection with unreachable sources * Improve protection against replay attacks on symmetric mode * Allow PHC refclock to use socket in /var/run/chrony * Add shutdown command to stop chronyd * Simplify format of response to manual list command * Improve handling of unknown responses in chronyc Bug fixes --------- * Respond to NTPv1 client requests with zero mode * Fix -x option to not require CAP_SYS_TIME under non-root user * Fix acquisitionport directive to work with privilege separation * Fix handling of socket errors on Linux to avoid high CPU usage * Fix chronyc to not get stuck in infinite loop after clock step New in version 3.2 ================== Enhancements ------------ * Improve stability with NTP sources and reference clocks * Improve stability with hardware timestamping * Improve support for NTP interleaved modes * Control frequency of system clock on macOS 10.13 and later * Set TAI-UTC offset of system clock with leapsectz directive * Minimise data in client requests to improve privacy * Allow transmit-only hardware timestamping * Add support for new timestamping options introduced in Linux 4.13 * Add root delay, root dispersion and maximum error to tracking log * Add mindelay and asymmetry options to server/peer/pool directive * Add extpps option to PHC refclock to timestamp external PPS signal * Add pps option to refclock directive to treat any refclock as PPS * Add width option to refclock directive to filter wrong pulse edges * Add rxfilter option to hwtimestamp directive * Add -x option to disable control of system clock * Add -l option to log to specified file instead of syslog * Allow multiple command-line options to be specified together * Allow starting without root privileges with -Q option * Update seccomp filter for new glibc versions * Dump history on exit by default with dumpdir directive * Use hardening compiler options by default Bug fixes --------- * Don't drop PHC samples with low-resolution system clock * Ignore outliers in PHC tracking, RTC tracking, manual input * Increase polling interval when peer is not responding * Exit with error message when include directive fails * Don't allow slash after hostname in allow/deny directive/command * Try to connect to all addresses in chronyc before giving up New in version 3.1 ================== Enhancements ------------ * Add support for precise cross timestamping of PHC on Linux * Add minpoll, precision, nocrossts options to hwtimestamp directive * Add rawmeasurements option to log directive and modify measurements option to log only valid measurements from synchronised sources * Allow sub-second polling interval with NTP sources Bug fixes --------- * Fix time smoothing in interleaved mode New in version 3.0 ================== Enhancements ------------ * Add support for software and hardware timestamping on Linux * Add support for client/server and symmetric interleaved modes * Add support for MS-SNTP authentication in Samba * Add support for truncated MACs in NTPv4 packets * Estimate and correct for asymmetric network jitter * Increase default minsamples and polltarget to improve stability with very low jitter * Add maxjitter directive to limit source selection by jitter * Add offset option to server/pool/peer directive * Add maxlockage option to refclock directive * Add -t option to chronyd to exit after specified time * Add partial protection against replay attacks on symmetric mode * Don't reset polling interval when switching sources to online state * Allow rate limiting with very short intervals * Improve maximum server throughput on Linux and NetBSD * Remove dump files after start * Add tab-completion to chronyc with libedit/readline * Add ntpdata command to print details about NTP measurements * Allow all source options to be set in add server/peer command * Indicate truncated addresses/hostnames in chronyc output * Print reference IDs as hexadecimal numbers to avoid confusion with IPv4 addresses Bug fixes --------- * Fix crash with disabled asynchronous name resolving New in version 2.4.1 ==================== Bug fixes --------- * Fix processing of kernel timestamps on non-Linux systems * Fix crash with smoothtime directive * Fix validation of refclock sample times * Fix parsing of refclock directive New in version 2.4 ================== Enhancements ------------ * Add orphan option to local directive for orphan mode compatible with ntpd * Add distance option to local directive to set activation threshold (1 second by default) * Add maxdrift directive to set maximum allowed drift of system clock * Try to replace NTP sources exceeding maximum distance * Randomise source replacement to avoid getting stuck with bad sources * Randomise selection of sources from pools on start * Ignore reference timestamp as ntpd doesn't always set it correctly * Modify tracking report to use same values as seen by NTP clients * Add -c option to chronyc to write reports in CSV format * Provide detailed manual pages Bug fixes --------- * Fix SOCK refclock to work correctly when not specified as last refclock * Fix initstepslew and -q/-Q options to accept time from own NTP clients * Fix authentication with keys using 512-bit hash functions * Fix crash on exit when multiple signals are received * Fix conversion of very small floating-point numbers in command packets Removed features ---------------- * Drop documentation in Texinfo format New in version 2.3 ================== Enhancements ------------ * Add support for NTP and command response rate limiting * Add support for dropping root privileges on Mac OS X, FreeBSD, Solaris * Add require and trust options for source selection * Enable logchange by default (1 second threshold) * Set RTC on Mac OS X with rtcsync directive * Allow binding to NTP port after dropping root privileges on NetBSD * Drop CAP_NET_BIND_SERVICE capability on Linux when NTP port is disabled * Resolve names in separate process when seccomp filter is enabled * Replace old records in client log when memory limit is reached * Don't reveal local time and synchronisation state in client packets * Don't keep client sockets open for longer than necessary * Ignore poll in KoD RATE packets as ntpd doesn't always set it correctly * Warn when using keys shorter than 80 bits * Add keygen command to generate random keys easily * Add serverstats command to report NTP and command packet statistics Bug fixes --------- * Fix clock correction after making step on Mac OS X * Fix building on Solaris New in version 2.2.1 ==================== Security fixes -------------- * Restrict authentication of NTP server/peer to specified key (CVE-2016-1567) New in version 2.2 ================== Enhancements ------------ * Add support for configuration and monitoring over Unix domain socket (accessible by root or chrony user when root privileges are dropped) * Add support for system call filtering with seccomp on Linux (experimental) * Add support for dropping root privileges on NetBSD * Control frequency of system clock on FreeBSD, NetBSD, Solaris * Add system leap second handling mode on FreeBSD, NetBSD, Solaris * Add dynamic drift removal on Mac OS X * Add support for setting real-time priority on Mac OS X * Add maxdistance directive to limit source selection by root distance (3 seconds by default) * Add refresh command to get new addresses of NTP sources * Allow wildcard patterns in include directive * Restore time from driftfile with -s option if later than RTC time * Add configure option to set default hwclockfile * Add -d option to chronyc to enable debug messages * Allow multiple addresses to be specified for chronyc with -h option and reconnect when no valid reply is received * Make check interval in waitsync command configurable Bug fixes --------- * Fix building on NetBSD, Solaris * Restore time from driftfile with -s option if reading RTC failed Removed features ---------------- * Drop support for authentication with command key (run-time configuration is now allowed only for local users that can access the Unix domain socket) New in version 2.1.1 ==================== Bug fixes --------- * Fix clock stepping by integer number of seconds on Linux New in version 2.1 ================== Enhancements ------------ * Add support for Mac OS X * Try to replace unreachable and falseticker servers/peers specified by name like pool sources * Add leaponly option to smoothtime directive to allow synchronised leap smear between multiple servers * Use specific reference ID when smoothing served time * Add smoothing command to report time smoothing status * Add smoothtime command to activate or reset time smoothing Bug fixes --------- * Fix crash in source selection with preferred sources * Fix resetting of time smoothing * Include packet precision in peer dispersion * Fix crash in chronyc on invalid command syntax New in version 2.0 ================== Enhancements ------------ * Update to NTP version 4 (RFC 5905) * Add pool directive to specify pool of NTP servers * Add leapsecmode directive to select how to correct clock for leap second * Add smoothtime directive to smooth served time and enable leap smear * Add minsources directive to set required number of selectable sources * Add minsamples and maxsamples options for all sources * Add tempcomp configuration with list of points * Allow unlimited number of NTP sources, refclocks and keys * Allow unreachable sources to remain selected * Improve source selection * Handle offline sources as unreachable * Open NTP server port only when necessary (client access is allowed by allow directive/command or peer/broadcast is configured) * Change default bindcmdaddress to loopback address * Change default maxdelay to 3 seconds * Change default stratumweight to 0.001 * Update adjtimex synchronisation status * Use system headers for adjtimex * Check for memory allocation errors * Reduce memory usage * Add configure options to compile without NTP, cmdmon, refclock support * Extend makestep command to set automatic clock stepping Bug fixes --------- * Add sanity checks for time and frequency offset * Don't report synchronised status during leap second * Don't combine reference clocks with close NTP sources * Fix accepting requests from configured sources * Fix initial fallback drift setting New in version 1.31.1 ===================== Security fixes -------------- * Protect authenticated symmetric NTP associations against DoS attacks (CVE-2015-1853) * Fix access configuration with subnet size indivisible by 4 (CVE-2015-1821) * Fix initialization of reply slots for authenticated commands (CVE-2015-1822) New in version 1.31 =================== Enhancements ------------ * Support operation in other NTP eras (next era begins in 2036), NTP time is mapped to [-50, +86] years around build date by default * Restore time from driftfile with -s when RTC is missing/unsupported * Close connected client sockets when not waiting for reply * Use one client socket with random port when acquisitionport is 0 * Use NTP packets instead of UDP echo for presend * Don't adjust polling interval when sending fails * Allow binding to addresses that don't exist yet * Ignore measurements around leap second * Improve detection of unexpected time jumps * Include example of logrotate configuration, systemd services and NetworkManager dispatcher script Bug fixes --------- * Reconnect client sockets for each request to follow changes in network configuration automatically * Restart timer when polling interval is changed on reset New in version 1.30 =================== Enhancements ------------ * Add asynchronous name resolving with POSIX threads * Add PTP hardware clock (PHC) refclock driver * Add new generic clock driver to slew by adjusting frequency only (without kernel PLL or adjtime) and use it on Linux * Add rtcautotrim directive to trim RTC automatically * Add hwclockfile directive to share RTC LOCAL/UTC setting with hwclock * Add maxslewrate directive to set maximum allowed slew rate * Add maxdispersion option for refclocks * Add -q/-Q options to set clock/print offset once and exit * Allow directives to be specified on chronyd command line * Replace frequency scaling in Linux driver with retaining of tick * Try to detect unexpected forward time jumps and reset state * Exit with non-zero code when maxchange limit is reached * Improve makestep to not start and stop slew unnecessarily * Change default corrtimeratio to 3.0 to improve frequency accuracy * Announce leap second only on last day of June and December * Use separate connected client sockets for each NTP server * Remove separate NTP implementation used for initstepslew * Limit maximum minpoll set by KoD RATE to default maxpoll * Don't send NTP requests with unknown key * Print warning when source is added with unknown key * Take leap second in PPS refclock from locked source * Make reading of RTC for initial trim more reliable * Don't create cmdmon sockets when cmdport is 0 * Add configure option to set default user to drop root privileges * Add configure option to compile with debug messages * Print debug messages when -d is used more than once * Change format of messages written to terminal with -d * Write fatal messages also to stderr with -n * Use IP_RECVERR socket option in chronyc to not wait unnecessarily * Shorten default chronyc timeout for localhost * Change default hostname in chronyc from localhost to 127.0.0.1 * Print error message on invalid syntax with all chronyc commands * Include simulation test suite using clknetsim Bug fixes --------- * Fix crash when selecting with multiple preferred sources * Fix frequency calculation with large frequency offsets * Fix code writing drift and RTC files to compile correctly * Fix -4/-6 options in chronyc to not reset hostname set by -h * Fix refclock sample validation with sub-second polling interval * Set stratum correctly with non-PPS SOCK refclock and local stratum * Modify dispersion accounting in refclocks to prevent PPS getting stuck with large dispersion and not accepting new samples New in version 1.29.1 ===================== Security fixes -------------- * Modify chronyc protocol to prevent amplification attacks (CVE-2014-0021) (incompatible with previous protocol version, chronyc supports both) New in version 1.29 =================== Security fixes -------------- * Fix crash when processing crafted commands (CVE-2012-4502) (possible with IP addresses allowed by cmdallow and localhost) * Don't send uninitialized data in SUBNETS_ACCESSED and CLIENT_ACCESSES replies (CVE-2012-4503) (not used by chronyc) Other changes ------------- * Drop support for SUBNETS_ACCESSED and CLIENT_ACCESSES commands New in version 1.28 =================== * Combine sources to improve accuracy * Make config and command parser strict * Add -a option to chronyc to authenticate automatically * Add -R option to ignore initstepslew and makestep directives * Add generatecommandkey, minsamples, maxsamples and user directives * Improve compatibility with NTPv1 and NTPv2 clients * Create sockets only in selected family with -4/-6 option * Treat address bind errors as non-fatal * Extend tracking log * Accept float values as initstepslew threshold * Allow hostnames in offline, online and burst commands * Fix and improve peer polling * Fix crash in config parsing with too many servers * Fix crash with duplicated initstepslew address * Fix delta calculation with extreme frequency offsets * Set local stratum correctly * Remove unnecessary adjtimex calls * Set paths in documentation by configure * Update chrony.spec New in version 1.27 =================== * Support for stronger keys via NSS or libtomcrypt library * Support reading leap second data from tz database * Support for precise clock stepping on Linux * Support for nanoseconds in SHM refclock * Make offset corrections smoother on Linux * Make transmit timestamps random below clock precision * Add corrtimeratio and maxchange directives * Extend tracking, sources and activity reports * Wait in foreground process until daemon is fully initialized * Fix crash with slow name resolving * Fix iburst with jittery sources * Fix offset stored in rtc data right after trimrtc * Fix crash and hang with RTC or manual samples * Don't use readonly adjtime on Linux kernels before 2.6.28 * Changed chronyc protocol, incompatible with older versions New in version 1.26 =================== * Add compatibility with Linux 3.0 and later * Use proper source address in NTP replies on multihomed IPv6 hosts * Accept NTP packets with versions 4, 3 and 2 * Cope with unexpected backward time jumps * Don't reset kernel frequency on start without drift file * Retry on permanent DNS error by default * Add waitsync command New in version 1.25 =================== * Improve accuracy with NTP sources * Improve accuracy with reference clocks * Improve polling interval adjustment * Improve stability with temporary asymmetric delays * Improve source selection * Improve initial synchronisation * Add delayed server name resolving * Add temperature compensation * Add nanosecond slewing to Linux driver * Add fallback drifts * Add iburst, minstratum, maxdelaydevratio, polltarget, prefer, noselect options * Add rtcsync directive to enable Linux 11-minute mode * Add reselectdist, stratumweight, logbanner, maxclockerror, include directives * Add -n option to not detach daemon from terminal * Fix pidfile directive * Fix name resolving with disabled IPv6 support * Fix reloading sample histories with reference clocks * Fix crash with auto_offline option * Fix online command on auto_offline sources * Fix file descriptor leaks * Increase burst polling interval and stop on KoD RATE * Set maxupdateskew to 1000 ppm by default * Require password for clients command * Update drift file at most once per hour * Use system headers for Linux RTC support * Reduce default chronyc timeout and make it configurable * Avoid large values in chronyc sources and sourcestats output * Add reselect command to force reselecting best source * Add -m option to allow multiple commands on command line New in version 1.24 =================== Security fixes -------------- * Don't reply to invalid cmdmon packets (CVE-2010-0292) * Limit client log memory size (CVE-2010-0293) * Limit rate of syslog messages (CVE-2010-0294) Bug fixes/Enhancements ---------------------- * Support for reference clocks (SHM, SOCK, PPS drivers) * IPv6 support * Linux capabilities support (to drop root privileges) * Memory locking support on Linux * Real-time scheduler support on Linux * Leap second support on Linux * Support for editline library * Support for new Linux readonly adjtime * NTP client support for KoD RATE * Read kernel timestamps for received NTP packets * Reply to NTP requests with correct address on multihomed hosts * Retry name resolving after temporary failure * Fix makestep command, make it available on all systems * Add makestep directive for automatic clock stepping * Don't require _bigadj kernel symbol on NetBSD * Avoid blocking read in Linux RTC driver * Support for Linux on S/390 and PowerPC * Fix various bugs on 64-bit systems * Fix valgrind errors and compiler warnings * Improve configure to support common options and variables * Improve status checking and printing in chronyc * Return non-zero exit code on errors in chronyc * Reduce request timeout in chronyc * Print estimated offset in sourcestats * Changed chronyc protocol, incompatible with older versions New in version 1.23 =================== * Support for MIPS, x86_64, sparc, alpha, arm, FreeBSD * Fix serious sign-extension error in handling IP addresses * RTC support can be excluded at compile time * Make sources gcc-4 compatible * Fix various compiler warnings * Handle fluctuations in peer distance better. * Fixed handling of stratum zero. * Fix various problems for 64-bit systems * Flush chronyc output streams after each command, to allow it to be driven through pipes * Manpage improvements Version 1.22 ============ This release number was claimed by a release that Mandriva made to patch important bugs in 1.21. The official numbering has jumped to 1.23 as a consequence. New in version 1.21 =================== * Don't include Linux kernel header files any longer : allows chrony to compile on recent distros. * Stop trying to use RTC if continuous streams of error messages would occur (Linux with HPET). New in version 1.20 =================== * Many small tidy-ups and security improvements * Improve documentation (RTC support in post 2.0 kernels) * Remove trailing \n from syslog messages * Syslog messages now include IP and port number when packet cannot be sent. * Added the "acquisitionport" directive. (Kalle Olavi Niemitalo) * Use uname(2) instead of /proc/version to get kernel version. * Merge support for Linux on Alpha * Merge support for 64bit architectures * Don't link -lm if it's not needed * Fix Solaris build (broken by 64bit change) * Add detection of Linux 2.5 * Allow arbitrary value of HZ in Linux kernel * Fix for chrony.spec on SuSE (Paul Elliot) * Fix handling of initstepslew if no servers are listed (John Hasler) * Fix install rule in Makefile if chronyd is in use (Juliusz Chroboczek) * Replace sprintf by snprintf to remove risk of buffer overrun (John Hasler) * Add --help to configure script New in version 1.19 =================== * Auto-detect kernel's timer interrupt rate (so-called 'HZ') when chronyd starts instead of relying on compiled-in value. * Fix 2 bugs in function that creates the directory for the log and dump files. * Amended webpage URL and contact details. * Generate more informative syslog messages before exiting on failed assertions. * Fix bugs in clamping code for the tick value used when slewing a large offset. * Don't chown files to root during install (should be pointless, and makes RPM building awkward as ordinary user.) * Include chrony.spec file for building RPMs New in version 1.18 =================== * Amend homepage and mailing list information to chrony.sunsite.dk * Delete pidfile on exit from chronyd. * Improvements to readline interface to chronyc * Only generate syslog message when synchronisation is initially lost (instead of on every failed synchronisation attempt) * Use double fork approach when initialising daemon. * More things in contrib directory. * New options to help package builders: --infodir/--mandir for configure, and DESTDIR=xxx for make. (See section 2.2 of chrony.txt for details). * Changed the wording of the messages generated by mailonchange and logchange directives. New in version 1.17 =================== * Port to NetBSD * Configuration supports Linux on PPC * Fix compilation warnings * Several documentation improvements * Bundled manpages (taken from the 'missing manpages project') * Cope with lack of bzero function for Solaris 2.3 systems * Store chronyd's pid in a file (default /var/run/chronyd.pid) and check if chronyd may already be running when starting up. New pidfile directive in configuration file. * Any size subnet is now allowed in allow and deny commands. (Example: 6.7.8/20 or 6.7.8.x/20 (any x) mean a 20 bit subnet). * The environment variables CC and CFLAGS passed to configure can now be used to select the compiler and optimisation/debug options to use * Write syslog messages when chronyd loses synchronisation. * Print GPL text when chronyc is run. * Add NTP broadcast server capability (new broadcast directive). * Add 'auto_offline' option to server/peer (conf file) or add server/peer (via chronyc). * Add 'activity' command to chronyc, to report how many servers/peers are currently online/offline. * Fix long-standing bug with how the system time quantum was calculated. * Include support for systems with HZ!=100 (HZ is the timer interrupt frequency). * Include example chrony.conf and chrony.keys files (examples subdirectory). * Include support for readline in chronyc. New in version 1.16.1 ===================== * Fix compilation problem on Linux 2.4.13 (spinlock.h / spinlock_t) New in version 1.16 =================== * More informative captions for 'sources' and 'sourcestats' commands in chronyc (use 'sources -v' and 'sourcestats -v' to get them). * Correct behaviour for Solaris versions>=2.6 (dosynctodr not required on these versions.) * Remove some compiler warnings (Solaris) * If last line of keys file doesn't have end-of-line, don't truncate final character of that key. * Change timestamp format used in logfiles to make it fully numeric (to aid importing data into spreadsheets etc) * Minor documentation updates and improvements. New in version 1.15 =================== * Add contributed change to 'configure' to support Solaris 2.8 on x86 * Workaround for assertion failure that arises if two received packets occur close together. (Still need to find out why this happens at all.) * Hopefully fix problem where fast slewing was incompatible with machines that have a large background drift rate (=> tick value went out of range for adjtimex() on Linux.) * Fix rtc_linux.c compile problems with 2.4.x kernel include files. * Include support for RTC device not being at /dev/rtc (new rtcdevice directive in configuration file). * Include support for restricting network interfaces for commands (new bindcmdaddress directive in configuration file) * Fix potential linking fault in pktlength.c (use of CROAK macro replaced by normal assert). * Add some material on bug reporting + contributing to the chrony.texi file * Made the chrony.texi file "Vim6-friendly" (removed xrefs on @node lines, added folding markers to chapters + sections.) * Switched over to GPL for the licence New in version 1.14 =================== * Fix compilation for certain other Linux distributions (including Mandrake 7.1) New in version 1.13 =================== * Fixed compilation problems on Redhat/SuSE installations with recent 2.2.x kernels. * Minor tidy-ups and documentation enhancements. * Add support for Linux 2.4 kernels New in version 1.12 =================== * Trial fix for long-standing bug in Linux RTC estimator when system time is slewed. * Fix bug in chronyc if -h is specified without a hostname * Fixes to logging various error conditions when operating in daemon mode. * More stuff under contrib/ * Changes to README file (e.g. about the new chrony-users mailing list) New in version 1.11a ==================== * Minor changes to contact details * Minor changes to installation details (chrony subdirectory under doc/) New in version 1.11 =================== * Improve robustness of installation procedure * Tidy up documenation and contact details * Distribute manual as .txt rather than as .ps * Add -n option to chronyc to work with numeric IP addresses rather than names. * Add material in contrib subdirectory * Improve robustness of handling drift file and RTC coefficients file * Improve robustness of regression algorithm New in version 1.1 ================== Bug fixes --------- * Made linear regression more resistant to rounding errors (old one occasionally generated negative variances which made everything go haywire). Trap infinite or 'not-a-number' values being used to alter system clock to increase robustness further. Other changes/Enhancements -------------------------- * Support for Linux 2.1 and 2.2 kernels * New command 'makestep' in chronyc to immediately jump the system time to match the NTP estimated time (Linux only) - a response to systems booting an hour wrong after summertime/wintertime changes, due to RTCs running on local time. Needs extending to Sun driver files too. * New directives 'logchange' and 'mailonchange' to log to syslog or email to a specific address respectively if chronyd detects a clock offset exceeding a defined threshold. * Added capability to log all client/peer NTP accesses and command accesses (can be turned off with conf file directive 'noclientlog'). Added 'clients' command to chronyc to display this data. * Improved manual mode to use robust regression rather than 2 point fit. * Added 'manual list' and 'manual delete' commands to chronyc to allow display of entered timestamps and discretionary deletion of outliers. * If host goes unsynchronised the dummy IP address 0.0.0.0 is detected to avoid attempting a reverse name lookup (to stop dial on demand IP links from being started) * Changed chronyc/chronyd protocol so messages are now all variable length. Saves on network bandwidth particularly for large replies from chronyd to chronyc (to support the clients command). * Added bindaddress directive to configuration file, to give additional control over limiting which hosts can access the local server. * Groundwork done for a port to Windows NT to compile with Cygwin toolkit. chronyc works (to monitor another host). sys_winnt.c needs finishing to use NT clock control API. Program structure needs adapting to use Windows NT service functions, so it can be started at boot time. Hopefully a Windows NT / Cygwin guru with some spare time can take this port over :-) New in version 1.02 =================== Bug fixes --------- * Fix error messages in chronyc if daemon is not reachable. * Fix config file problem for 'allow all' and 'deny all' without a trailing machine address. * Remove fatal failed assertion if command socket cannot be read from in daemon. * Rewrote timezone handling for Linux real time clock, following various reported problems related to daylight saving. Other changes/Enhancements -------------------------- * Configure script recognizes BSD/386 and uses SunOS 4.1 driver for it. * Log files now print date as day-month-year rather than as a day number. Milliseconds removed from timestamps of logged data. Banners included in file to give meanings of columns. * Only do 1 initial step (followed by a trimming slew) when initialising from RTC on Linux (previously did 2 steps). New in version 1.01 =================== Bug fixes --------- * Handle timezone of RTC correctly with respect to daylight saving time * Syntax check the chronyc 'local' command properly * Fixed assertion failed fault in median finder (used by RTC regression fitting) Other changes/Enhancements -------------------------- * Log selection of new NTP reference source to syslog. * Don't zero-pad IP address fields * Add new command to chronyc to allow logfiles to be cycled. * Extend allow/deny directive syntax in configuration file to so directive can apply to all hosts on the Internet. * Tidy up printout of timestamps to make it clear they are in UTC * Make 'configure' check the processor type as well as the operating system.
README
Zum Öffnen der im WIKI abgelegten README-Page auf die grauen Balken klicken!
$ less /usr/share/doc/chrony/README
This is the README for chrony.
What is chrony?
===============
chrony is a versatile implementation of the Network Time Protocol (NTP).
It can synchronise the system clock with NTP servers, reference clocks
(e.g. GPS receiver), and manual input using wristwatch and keyboard.
It can also operate as an NTPv4 (RFC 5905) server and peer to provide
a time service to other computers in the network.
It is designed to perform well in a wide range of conditions, including
intermittent network connections, heavily congested networks, changing
temperatures (ordinary computer clocks are sensitive to temperature),
and systems that do not run continuosly, or run on a virtual machine.
Typical accuracy between two machines synchronised over the Internet is
within a few milliseconds; on a LAN, accuracy is typically in tens of
microseconds. With hardware timestamping, or a hardware reference clock,
sub-microsecond accuracy may be possible.
Two programs are included in chrony, chronyd is a daemon that can be
started at boot time and chronyc is a command-line interface program
which can be used to monitor chronyd's performance and to change various
operating parameters whilst it is running.
What will chrony run on?
========================
The software is known to work on Linux, FreeBSD, NetBSD, macOS and
illumos. Closely related systems may work too. Any other system will
likely require a porting exercise.
How do I set it up?
===================
The file INSTALL gives instructions. On supported systems the
compilation process should be automatic. You will need a C compiler,
e.g. gcc or clang.
What documentation is there?
============================
The distribution includes manual pages and a document containing
Frequently Asked Questions (FAQ).
The documentation is also available on the chrony web pages, accessible
through the URL
https://chrony-project.org/
License
=======
chrony is distributed under the GNU General Public License version 2.
Authors
=======
Richard P. Curnow <rc@rc0.org.uk>
Miroslav Lichvar <mlichvar@redhat.com>
Acknowledgements
================
In writing the chronyd program, extensive use has been made of the NTPv3 (RFC
1305) and NTPv4 (RFC 5905) specification. The source code of the xntpd/ntpd
implementation written by Dennis Fergusson, Lars Mathiesen, David Mills, and
others has been used to check the details of the protocol.
The following people have provided patches and other major contributions
to chrony:
Lonnie Abelbeck <lonnie@abelbeck.com>
Benny Lyne Amorsen <benny@amorsen.dk>
Andrew Bishop <amb@gedanken.demon.co.uk>
Vincent Blut <vincent.debian@free.fr>
Stephan I. Boettcher <stephan@nevis1.columbia.edu>
David Bohman <debohman@gmail.com>
Goswin Brederlow <brederlo@informatik.uni-tuebingen.de>
Leigh Brown <leigh@solinno.co.uk>
Erik Bryer <ebryer@spots.ab.ca>
Jonathan Cameron <jic23@cam.ac.uk>
Bryan Christianson <bryan@whatroute.net>
Juliusz Chroboczek <jch@pps.jussieu.fr>
Dan Drown <dan-ntp@drown.org>
Kamil Dudka <kdudka@redhat.com>
Christian Ehrhardt <christian.ehrhardt@canonical.com>
Paul Elliott <pelliott@io.com>
Robert Fairley <rfairley@redhat.com>
Stefan R. Filipek <srfilipek@gmail.com>
Mike Fleetwood <mike@rockover.demon.co.uk>
Alexander Gretencord <arutha@gmx.de>
Andrew Griffiths <agriffit@redhat.com>
Walter Haidinger <walter.haidinger@gmx.at>
Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
John Hasler <john@dhh.gt.org>
Tjalling Hattink <t.hattink@fugro.nl>
Liam Hatton <me@liamhatton.com>
Holger Hoffstätte <holger@applied-asynchrony.com>
Jachym Holecek <jakym@volny.cz>
Håkan Johansson <f96hajo@chalmers.se>
Jim Knoble <jmknoble@pobox.com>
Antti Jrvinen <costello@iki.fi>
Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Eric Lammerts <eric@lammerts.org>
Stefan Lucke <stefan@lucke.in-berlin.de>
Victor Lum <viclum@vanu.com>
Kevin Lyda <kevin@ie.suberic.net>
Paul Menzel <paulepanter@users.sourceforge.net>
Vladimir Michl <vladimir.michl@seznam.cz>
Victor Moroz <vim@prv.adlum.ru>
Kalle Olavi Niemitalo <tosi@stekt.oulu.fi>
Frank Otto <sandwichmacher@web.de>
Denny Page <dennypage@me.com>
Rupesh Patel <rupatel@redhat.com>
Chris Perl <cperl@janestreet.com>
Gautier PHILIPPON <gautier.philippon@ensimag.grenoble-inp.fr>
Andreas Piesk <apiesk@virbus.de>
Mike Ryan <msr@hsilop.net>
Baruch Siach <baruch@tkos.co.il>
Josef 'Jeff' Sipek <jeffpc@josefsipek.net>
Foster Snowhill <forst@forstwoof.ru>
Andreas Steinmetz <ast@domdv.de>
NAKAMURA Takumi <takumi@ps.sakura.ne.jp>
Timo Teras <timo.teras@iki.fi>
Bill Unruh <unruh@physics.ubc.ca>
Luke Valenta <lvalenta@cloudflare.com>
Stephen Wadeley <swadeley@redhat.com>
Bernhard Weiss <lisnablagh@web.de>
Wolfgang Weisselberg <weissel@netcologne.de>
Bernhard M. Wiedemann <bwiedemann@suse.de>
Joachim Wiedorn <ad_debian@joonet.de>
Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>
Michael Witten <mfwitten@gmail.com>
Doug Woodward <dougw@whistler.com>
Thomas Zajic <zlatko@zlatko.fdns.net>
Many other people have contributed bug reports and suggestions. We are sorry
we cannot identify all of you individually.
Konfiguration
Wie schon zuvor angemerkt, finden sich im Verzeichnis /usr/share/doc/chrony/examples/ entsprechen hilfreiche Konfigurationsbeispiele.
# tree /usr/share/doc/chrony/examples/
/usr/share/doc/chrony/examples/ ├── chrony.conf.example1 ├── chrony.conf.example2 ├── chrony.conf.example3 ├── chronyd-restricted.service ├── chronyd.service ├── chrony.keys.example ├── chrony.logrotate ├── chrony.nm-dispatcher.dhcp ├── chrony.nm-dispatcher.onoffline └── chrony-wait.service
Wir wollen uns nun zwei Standardkonfigurationsbeispiele nun nachfolgend etwas genauer ansehen.
Bevor wir nun aber unseren Chrony-Daemon - egal ob wird nun chrony als Server oder als Client betreiben wollen - werden wir zunächst die im Paket mitgelieferte Original-Konfigurationsdatei /etc/chrony.conf für spätere Referenzen sichern.
# cp -a /etc/chrony.conf /etc/chrony.conf.orig
Zum Öffnen der im WIKI abgelegten originalen KOnfigurationsdatei /etc/chrony.conf.orig auf die grauen Balken klicken!
$ less /etc/chrony.conf.orig
- /etc/chrony.conf.orig
####################################################################### # # This is an example chrony configuration file. You should copy it to # /etc/chrony.conf after uncommenting and editing the options that you # want to enable. The more obscure options are not included. Refer # to the documentation for these. # ####################################################################### ### COMMENTS # Any of the following lines are comments (you have a choice of # comment start character): # a comment % a comment ! a comment ; a comment # # Below, the '!' form is used for lines that you might want to # uncomment and edit to make your own chrony.conf file. # ####################################################################### ####################################################################### ### SPECIFY YOUR NTP SERVERS # Most computers using chrony will send measurement requests to one or # more 'NTP servers'. You will probably find that your Internet Service # Provider or company have one or more NTP servers that you can specify. # Failing that, there are a lot of public NTP servers. There is a list # you can access at http://support.ntp.org/bin/view/Servers/WebHome or # you can use servers from the pool.ntp.org project. ! server ntp1.example.net iburst ! server ntp2.example.net iburst ! server ntp3.example.net iburst pool 2.arch.pool.ntp.org iburst ####################################################################### ### AVOIDING POTENTIALLY BOGUS CHANGES TO YOUR CLOCK # # To avoid changes being made to your computer's gain/loss compensation # when the measurement history is too erratic, you might want to enable # one of the following lines. The first seems good with servers on the # Internet, the second seems OK for a LAN environment. ! maxupdateskew 100 ! maxupdateskew 5 # If you want to increase the minimum number of selectable sources # required to update the system clock in order to make the # synchronisation more reliable, uncomment (and edit) the following # line. ! minsources 2 # If your computer has a good stable clock (e.g. it is not a virtual # machine), you might also want to reduce the maximum assumed drift # (frequency error) of the clock (the value is specified in ppm). ! maxdrift 100 # By default, chronyd allows synchronisation to an unauthenticated NTP # source (i.e. specified without the nts and key options) if it agrees with # a majority of authenticated NTP sources, or if no authenticated source is # specified. If you don't want chronyd to ever synchronise to an # unauthenticated NTP source, uncomment the first from the following lines. # If you don't want to synchronise to an unauthenticated NTP source only # when an authenticated source is specified, uncomment the second line. # If you want chronyd to ignore authentication in the source selection, # uncomment the third line. ! authselectmode require ! authselectmode prefer ! authselectmode ignore ####################################################################### ### FILENAMES ETC # Chrony likes to keep information about your computer's clock in files. # The 'driftfile' stores the computer's clock gain/loss rate in parts # per million. When chronyd starts, the system clock can be tuned # immediately so that it doesn't gain or lose any more time. You # generally want this, so it is uncommented. driftfile /var/lib/chrony/drift # If you want to enable NTP authentication with symmetric keys, you will need # to uncomment the following line and edit the file to set up the keys. ! keyfile /etc/chrony.keys # If you specify an NTP server with the nts option to enable authentication # with the Network Time Security (NTS) mechanism, or enable server NTS with # the ntsservercert and ntsserverkey directives below, the following line will # allow the client/server to save the NTS keys and cookies in order to reduce # the number of key establishments (NTS-KE sessions). ntsdumpdir /var/lib/chrony # If chronyd is configured to act as an NTP server and you want to enable NTS # for its clients, you will need a TLS certificate and private key. Uncomment # and edit the following lines to specify the locations of the certificate and # key. ! ntsservercert /etc/.../nts-server.crt ! ntsserverkey /etc/.../nts-server.key # chronyd can save the measurement history for the servers to files when # it exits. This is useful in 2 situations: # # 1. If you stop chronyd and restart it with the '-r' option (e.g. after # an upgrade), the old measurements will still be relevant when chronyd # is restarted. This will reduce the time needed to get accurate # gain/loss measurements. # # 2. On Linux, if you use the RTC support and start chronyd with # '-r -s' on bootup, measurements from the last boot will still be # useful (the real time clock is used to 'flywheel' chronyd between # boots). # # Uncomment the following line to use this. ! dumpdir /var/lib/chrony # chronyd writes its process ID to a file. If you try to start a second # copy of chronyd, it will detect that the process named in the file is # still running and bail out. If you want to change the path to the PID # file, uncomment this line and edit it. The default path is shown. ! pidfile /var/run/chrony/chronyd.pid # If the system timezone database is kept up to date and includes the # right/UTC timezone, chronyd can use it to determine the current # TAI-UTC offset and when will the next leap second occur. leapsectz right/UTC ####################################################################### ### INITIAL CLOCK CORRECTION # This option is useful to quickly correct the clock on start if it's # off by a large amount. The value '1.0' means that if the error is less # than 1 second, it will be gradually removed by speeding up or slowing # down your computer's clock until it is correct. If the error is above # 1 second, an immediate time jump will be applied to correct it. The # value '3' means the step is allowed only in the first three updates of # the clock. Some software can get upset if the system clock jumps # (especially backwards), so be careful! makestep 1.0 3 ####################################################################### ### LEAP SECONDS # A leap second is an occasional one-second correction of the UTC # time scale. By default, chronyd tells the kernel to insert/delete # the leap second, which makes a backward/forward step to correct the # clock for it. As with the makestep directive, this jump can upset # some applications. If you prefer chronyd to make a gradual # correction, causing the clock to be off for a longer time, uncomment # the following line. ! leapsecmode slew ####################################################################### ### LOGGING # If you want to log information about the time measurements chronyd has # gathered, you might want to enable the following lines. You probably # only need this if you really enjoy looking at the logs, you want to # produce some graphs of your system's timekeeping performance, or you # need help in debugging a problem. ! logdir /var/log/chrony ! log measurements statistics tracking # If you have real time clock support enabled (see below), you might want # this line instead: ! log measurements statistics tracking rtc ####################################################################### ### ACTING AS AN NTP SERVER # You might want the computer to be an NTP server for other computers. # # By default, chronyd does not allow any clients to access it. You need # to explicitly enable access using 'allow' and 'deny' directives. # # e.g. to enable client access from the 192.168.*.* class B subnet, ! allow 192.168/16 # .. but disallow the 192.168.100.* subnet of that, ! deny 192.168.100/24 # You can have as many allow and deny directives as you need. The order # is unimportant. # If you want to present your computer's time for others to synchronise # with, even if you don't seem to be synchronised to any NTP servers # yourself, enable the following line. The value 10 may be varied # between 1 and 15. You should avoid small values because you will look # like a real NTP server. The value 10 means that you appear to be 10 # NTP 'hops' away from an authoritative source (atomic clock, GPS # receiver, radio clock etc). ! local stratum 10 # Normally, chronyd will keep track of how many times each client # machine accesses it. The information can be accessed by the 'clients' # command of chronyc. You can disable this facility by uncommenting the # following line. This will save a bit of memory if you have many # clients and it will also disable support for the interleaved mode. ! noclientlog # The clientlog size is limited to 512KB by default. If you have many # clients, you might want to increase the limit. ! clientloglimit 4194304 # By default, chronyd tries to respond to all valid NTP requests from # allowed addresses. If you want to limit the response rate for NTP # clients that are sending requests too frequently, uncomment and edit # the following line. ! ratelimit interval 3 burst 8 ####################################################################### ### REPORTING BIG CLOCK CHANGES # Perhaps you want to know if chronyd suddenly detects any large error # in your computer's clock. This might indicate a fault or a problem # with the server(s) you are using, for example. # # The next option causes a message to be written to syslog when chronyd # has to correct an error above 0.5 seconds (you can use any amount you # like). ! logchange 0.5 # The next option will send email to the named person when chronyd has # to correct an error above 0.5 seconds. (If you need to send mail to # several people, you need to set up a mailing list or sendmail alias # for them and use the address of that.) ! mailonchange wibble@example.net 0.5 ####################################################################### ### COMMAND ACCESS # The program chronyc is used to show the current operation of chronyd # and to change parts of its configuration whilst it is running. # By default chronyd binds to the loopback interface. Uncomment the # following lines to allow receiving command packets from remote hosts. ! bindcmdaddress 0.0.0.0 ! bindcmdaddress :: # Normally, chronyd will only allow connections from chronyc on the same # machine as itself. This is for security. If you have a subnet # 192.168.*.* and you want to be able to use chronyc from any machine on # it, you could uncomment the following line. (Edit this to your own # situation.) ! cmdallow 192.168/16 # You can add as many 'cmdallow' and 'cmddeny' lines as you like. The # syntax and meaning is the same as for 'allow' and 'deny', except that # 'cmdallow' and 'cmddeny' control access to the chronyd's command port. # Rate limiting can be enabled also for command packets. (Note, # commands from localhost are never limited.) ! cmdratelimit interval -4 burst 16 ####################################################################### ### HARDWARE TIMESTAMPING # On Linux, if the network interface controller and its driver support # hardware timestamping, it can significantly improve the accuracy of # synchronisation. It can be enabled on specified interfaces only, or it # can be enabled on all interfaces that support it. ! hwtimestamp eth0 ! hwtimestamp * ####################################################################### ### REAL TIME CLOCK # chronyd can characterise the system's real-time clock. This is the # clock that keeps running when the power is turned off, so that the # machine knows the approximate time when it boots again. The error at # a particular epoch and gain/loss rate can be written to a file and # used later by chronyd when it is started with the '-s' option. # # You need to have 'enhanced RTC support' compiled into your Linux # kernel. (Note, these options apply only to Linux.) ! rtcfile /var/lib/chrony/rtc # Your RTC can be set to keep Universal Coordinated Time (UTC) or local # time. (Local time means UTC +/- the effect of your timezone.) If you # use UTC, chronyd will function correctly even if the computer is off # at the epoch when you enter or leave summer time (aka daylight saving # time). However, if you dual boot your system with Microsoft Windows, # that will work better if your RTC maintains local time. You take your # pick! ! rtconutc # By default chronyd assumes that the enhanced RTC device is accessed as # /dev/rtc. If it's accessed somewhere else on your system (e.g. you're # using devfs), uncomment and edit the following line. ! rtcdevice /dev/misc/rtc # Alternatively, if not using the -s option, this directive can be used # to enable a mode in which the RTC is periodically set to the system # time, with no tracking of its drift. rtcsync ####################################################################### ### REAL TIME SCHEDULER # This directive tells chronyd to use the real-time FIFO scheduler with the # specified priority (which must be between 0 and 100). This should result # in reduced latency. You don't need it unless you really have a requirement # for extreme clock stability. Works only on Linux. Note that the "-P" # command-line switch will override this. ! sched_priority 1 ####################################################################### ### LOCKING CHRONYD INTO RAM # This directive tells chronyd to use the mlockall() syscall to lock itself # into RAM so that it will never be paged out. This should result in reduced # latency. You don't need it unless you really have a requirement # for extreme clock stability. Works only on Linux. Note that the "-m" # command-line switch will also enable this feature. ! lock_all
So können wir bei etwaigen Bedarf Vergleiche zur originalen Konfigurationsdatei mit unserer individuellen Konfigurationsdatei anstreben, wie in diesem Beispiel hier:
# vimdiff /etc/chrony.conf /etc/chrony.conf.orig
Client
Bei der Konfiguration unseres chrony-Clients reicht es völlig aus, wenn wir uns auf die Definition unseres Timeserver(pools) beschränken. Alle anderen Optionen in der mitgelieferten Konfigurationsdatei sind bereits auf valide Grundwerte gesetzt, so dass wir uns hier nicht gross weiter mit Details beschäftigen müssen.
Im Abschnitt SPECIFY YOUR NTP SERVERS hinterlegen wir nun also den NTP-Server unserer Wahl.
# vim /etc/chrony.conf
- /etc/chrony.conf
... ####################################################################### ####################################################################### ### SPECIFY YOUR NTP SERVERS # Most computers using chrony will send measurement requests to one or # more 'NTP servers'. You will probably find that your Internet Service # Provider or company have one or more NTP servers that you can specify. # Failing that, there are a lot of public NTP servers. There is a list # you can access at http://support.ntp.org/bin/view/Servers/WebHome or # you can use servers from the pool.ntp.org project. ! server ntp1.example.net iburst ! server ntp2.example.net iburst ! server ntp3.example.net iburst server time.dmz.nausch.org iburst ...
Vereinfacht zusammengefasst ist dies im Grunde die Beispielskonfigurationsdatei die /usr/share/doc/chrony/examples/chrony.conf.example1 die uns das Paket chrony hat mitgeliefert - wir haben hier „nur“ unseren eigenen NTP-Server eingetragen.
# less /usr/share/doc/chrony/examples/chrony.conf.example1
- /usr/share/doc/chrony/examples/chrony.conf.example1
# Use public NTP servers from the pool.ntp.org project. pool 2.arch.pool.ntp.org iburst # Record the rate at which the system clock gains/losses time. driftfile /var/lib/chrony/drift # Allow the system clock to be stepped in the first three updates # if its offset is larger than 1 second. makestep 1.0 3 # Enable kernel synchronization of the real-time clock (RTC). rtcsync
Server
Chrony Daemon
Im zweiten Konfigurationsbeispiel widmen wir uns unserem Arch Linux Server, der als interner Zeitserver agieren und der von mehreren vertrauenswürdigen NTP-Server im Internet die Uhrzeit holen und auch synchron halten soll.
Die Konfiguration unseres Chrony-Daemon, oder genauer gesagt unseres NTP-Servers mit Hilfe von chrony, erfolgt wie auch bei der zuvor gezeigten Clientkonfiguration über die Datei /etc/chrony.conf. Mit dem Editor unserer Wahl bearbeiten wir nun diese Datei. In nachfolgendem Konfigurationsbeispiel wurden alle relavanten Änderungen mit Admin-Name und Datum versehen, also z.B. # Django : 2024-02-18
# vim /etc/chrony.conf
- /etc/chrony.conf
####################################################################### # # This is an example chrony configuration file. You should copy it to # /etc/chrony.conf after uncommenting and editing the options that you # want to enable. The more obscure options are not included. Refer # to the documentation for these. # ####################################################################### ### COMMENTS # Any of the following lines are comments (you have a choice of # comment start character): # a comment % a comment ! a comment ; a comment # # Below, the '!' form is used for lines that you might want to # uncomment and edit to make your own chrony.conf file. # ####################################################################### ####################################################################### ### SPECIFY YOUR NTP SERVERS # Most computers using chrony will send measurement requests to one or # more 'NTP servers'. You will probably find that your Internet Service # Provider or company have one or more NTP servers that you can specify. # Failing that, there are a lot of public NTP servers. There is a list # you can access at http://support.ntp.org/bin/view/Servers/WebHome or # you can use servers from the pool.ntp.org project. ! server ntp1.example.net iburst ! server ntp2.example.net iburst ! server ntp3.example.net iburst # Django : 2024-02-18 server pool.ntp.org iburst ####################################################################### ### AVOIDING POTENTIALLY BOGUS CHANGES TO YOUR CLOCK # # To avoid changes being made to your computer's gain/loss compensation # when the measurement history is too erratic, you might want to enable # one of the following lines. The first seems good with servers on the # Internet, the second seems OK for a LAN environment. ! maxupdateskew 100 ! maxupdateskew 5 # If you want to increase the minimum number of selectable sources # required to update the system clock in order to make the # synchronisation more reliable, uncomment (and edit) the following # line. ! minsources 2 # If your computer has a good stable clock (e.g. it is not a virtual # machine), you might also want to reduce the maximum assumed drift # (frequency error) of the clock (the value is specified in ppm). ! maxdrift 100 # By default, chronyd allows synchronisation to an unauthenticated NTP # source (i.e. specified without the nts and key options) if it agrees with # a majority of authenticated NTP sources, or if no authenticated source is # specified. If you don't want chronyd to ever synchronise to an # unauthenticated NTP source, uncomment the first from the following lines. # If you don't want to synchronise to an unauthenticated NTP source only # when an authenticated source is specified, uncomment the second line. # If you want chronyd to ignore authentication in the source selection, # uncomment the third line. ! authselectmode require ! authselectmode prefer ! authselectmode ignore ####################################################################### ### FILENAMES ETC # Chrony likes to keep information about your computer's clock in files. # The 'driftfile' stores the computer's clock gain/loss rate in parts # per million. When chronyd starts, the system clock can be tuned # immediately so that it doesn't gain or lose any more time. You # generally want this, so it is uncommented. driftfile /var/lib/chrony/drift # If you want to enable NTP authentication with symmetric keys, you will need # to uncomment the following line and edit the file to set up the keys. ! keyfile /etc/chrony.keys # If you specify an NTP server with the nts option to enable authentication # with the Network Time Security (NTS) mechanism, or enable server NTS with # the ntsservercert and ntsserverkey directives below, the following line will # allow the client/server to save the NTS keys and cookies in order to reduce # the number of key establishments (NTS-KE sessions). ntsdumpdir /var/lib/chrony # If chronyd is configured to act as an NTP server and you want to enable NTS # for its clients, you will need a TLS certificate and private key. Uncomment # and edit the following lines to specify the locations of the certificate and # key. ! ntsservercert /etc/.../nts-server.crt ! ntsserverkey /etc/.../nts-server.key # chronyd can save the measurement history for the servers to files when # it exits. This is useful in 2 situations: # # 1. If you stop chronyd and restart it with the '-r' option (e.g. after # an upgrade), the old measurements will still be relevant when chronyd # is restarted. This will reduce the time needed to get accurate # gain/loss measurements. # # 2. On Linux, if you use the RTC support and start chronyd with # '-r -s' on bootup, measurements from the last boot will still be # useful (the real time clock is used to 'flywheel' chronyd between # boots). # # Uncomment the following line to use this. ! dumpdir /var/lib/chrony # Django : 2024-02-18 dumpdir /var/lib/chrony # chronyd writes its process ID to a file. If you try to start a second # copy of chronyd, it will detect that the process named in the file is # still running and bail out. If you want to change the path to the PID # file, uncomment this line and edit it. The default path is shown. ! pidfile /var/run/chrony/chronyd.pid # If the system timezone database is kept up to date and includes the # right/UTC timezone, chronyd can use it to determine the current # TAI-UTC offset and when will the next leap second occur. leapsectz right/UTC ####################################################################### ### INITIAL CLOCK CORRECTION # This option is useful to quickly correct the clock on start if it's # off by a large amount. The value '1.0' means that if the error is less # than 1 second, it will be gradually removed by speeding up or slowing # down your computer's clock until it is correct. If the error is above # 1 second, an immediate time jump will be applied to correct it. The # value '3' means the step is allowed only in the first three updates of # the clock. Some software can get upset if the system clock jumps # (especially backwards), so be careful! makestep 1.0 3 ####################################################################### ### LEAP SECONDS # A leap second is an occasional one-second correction of the UTC # time scale. By default, chronyd tells the kernel to insert/delete # the leap second, which makes a backward/forward step to correct the # clock for it. As with the makestep directive, this jump can upset # some applications. If you prefer chronyd to make a gradual # correction, causing the clock to be off for a longer time, uncomment # the following line. ! leapsecmode slew ####################################################################### ### LOGGING # If you want to log information about the time measurements chronyd has # gathered, you might want to enable the following lines. You probably # only need this if you really enjoy looking at the logs, you want to # produce some graphs of your system's timekeeping performance, or you # need help in debugging a problem. ! logdir /var/log/chrony ! log measurements statistics tracking # If you have real time clock support enabled (see below), you might want # this line instead: ! log measurements statistics tracking rtc ####################################################################### ### ACTING AS AN NTP SERVER # You might want the computer to be an NTP server for other computers. # # By default, chronyd does not allow any clients to access it. You need # to explicitly enable access using 'allow' and 'deny' directives. # # e.g. to enable client access from the 192.168.*.* class B subnet, ! allow 192.168/16 # Django : 2024-02-18 allow 10.0.0.0/24 allow 2003:a:e0d:7603::/64 allow 192.168.0.0/24 allow 2003:a:e0d:7607::/64 # .. but disallow the 192.168.100.* subnet of that, ! deny 192.168.100/24 # You can have as many allow and deny directives as you need. The order # is unimportant. # If you want to present your computer's time for others to synchronise # with, even if you don't seem to be synchronised to any NTP servers # yourself, enable the following line. The value 10 may be varied # between 1 and 15. You should avoid small values because you will look # like a real NTP server. The value 10 means that you appear to be 10 # NTP 'hops' away from an authoritative source (atomic clock, GPS # receiver, radio clock etc). ! local stratum 10 # Django : 2024-02-18 local stratum 3 # Normally, chronyd will keep track of how many times each client # machine accesses it. The information can be accessed by the 'clients' # command of chronyc. You can disable this facility by uncommenting the # following line. This will save a bit of memory if you have many # clients and it will also disable support for the interleaved mode. ! noclientlog # The clientlog size is limited to 512KB by default. If you have many # clients, you might want to increase the limit. ! clientloglimit 4194304 # By default, chronyd tries to respond to all valid NTP requests from # allowed addresses. If you want to limit the response rate for NTP # clients that are sending requests too frequently, uncomment and edit # the following line. ! ratelimit interval 3 burst 8 ####################################################################### ### REPORTING BIG CLOCK CHANGES # Perhaps you want to know if chronyd suddenly detects any large error # in your computer's clock. This might indicate a fault or a problem # with the server(s) you are using, for example. # # The next option causes a message to be written to syslog when chronyd # has to correct an error above 0.5 seconds (you can use any amount you # like). ! logchange 0.5 # Django : 2027-02-18 logchange 0.5 # The next option will send email to the named person when chronyd has # to correct an error above 0.5 seconds. (If you need to send mail to # several people, you need to set up a mailing list or sendmail alias # for them and use the address of that.) ! mailonchange wibble@example.net 0.5 # Django : 2024-02-18 mailonchange django@nausch.org 0.5 ####################################################################### ### COMMAND ACCESS # The program chronyc is used to show the current operation of chronyd # and to change parts of its configuration whilst it is running. # By default chronyd binds to the loopback interface. Uncomment the # following lines to allow receiving command packets from remote hosts. ! bindcmdaddress 0.0.0.0 ! bindcmdaddress :: # Normally, chronyd will only allow connections from chronyc on the same # machine as itself. This is for security. If you have a subnet # 192.168.*.* and you want to be able to use chronyc from any machine on # it, you could uncomment the following line. (Edit this to your own # situation.) ! cmdallow 192.168/16 # You can add as many 'cmdallow' and 'cmddeny' lines as you like. The # syntax and meaning is the same as for 'allow' and 'deny', except that # 'cmdallow' and 'cmddeny' control access to the chronyd's command port. # Rate limiting can be enabled also for command packets. (Note, # commands from localhost are never limited.) ! cmdratelimit interval -4 burst 16 ####################################################################### ### HARDWARE TIMESTAMPING # On Linux, if the network interface controller and its driver support # hardware timestamping, it can significantly improve the accuracy of # synchronisation. It can be enabled on specified interfaces only, or it # can be enabled on all interfaces that support it. ! hwtimestamp eth0 ! hwtimestamp * ####################################################################### ### REAL TIME CLOCK # chronyd can characterise the system's real-time clock. This is the # clock that keeps running when the power is turned off, so that the # machine knows the approximate time when it boots again. The error at # a particular epoch and gain/loss rate can be written to a file and # used later by chronyd when it is started with the '-s' option. # # You need to have 'enhanced RTC support' compiled into your Linux # kernel. (Note, these options apply only to Linux.) ! rtcfile /var/lib/chrony/rtc # Your RTC can be set to keep Universal Coordinated Time (UTC) or local # time. (Local time means UTC +/- the effect of your timezone.) If you # use UTC, chronyd will function correctly even if the computer is off # at the epoch when you enter or leave summer time (aka daylight saving # time). However, if you dual boot your system with Microsoft Windows, # that will work better if your RTC maintains local time. You take your # pick! ! rtconutc # By default chronyd assumes that the enhanced RTC device is accessed as # /dev/rtc. If it's accessed somewhere else on your system (e.g. you're # using devfs), uncomment and edit the following line. ! rtcdevice /dev/misc/rtc # Alternatively, if not using the -s option, this directive can be used # to enable a mode in which the RTC is periodically set to the system # time, with no tracking of its drift. rtcsync ####################################################################### ### REAL TIME SCHEDULER # This directive tells chronyd to use the real-time FIFO scheduler with the # specified priority (which must be between 0 and 100). This should result # in reduced latency. You don't need it unless you really have a requirement # for extreme clock stability. Works only on Linux. Note that the "-P" # command-line switch will override this. ! sched_priority 1 ####################################################################### ### LOCKING CHRONYD INTO RAM # This directive tells chronyd to use the mlockall() syscall to lock itself # into RAM so that it will never be paged out. This should result in reduced # latency. You don't need it unless you really have a requirement # for extreme clock stability. Works only on Linux. Note that the "-m" # command-line switch will also enable this feature. ! lock_all # Django : 2024-02-18 lock_all
Die relevanten KOnfigurationsoptionen können wir mit Hilfe von grep uns auch gerafft anzeigen lassen.
# grep -Ev '(^%|^$|^#|^!|^;)' /etc/chrony.conf
server pool.ntp.org iburst driftfile /var/lib/chrony/drift ntsdumpdir /var/lib/chrony dumpdir /var/lib/chrony leapsectz right/UTC makestep 1.0 3 allow 10.0.0.0/24 allow 2003:a:e0d:7603::/64 allow 192.168.0.0/24 allow 2003:a:e0d:7607::/64 local stratum 3 logchange 0.5 mailonchange django@nausch.org 0.5 rtcsync lock_all
Paketfilter - firewalld
Wie auch schon früher bei CentOS ab Release 7 bzw. den nachfolgenden Relaese-Kandidaten Stream von RHEL nutzen wir auch unter Arch Linux den dynamischen firewalld Service. Ein grosser Vorteil der dynamischen Paketfilterregeln ist unter anderem, dass zur Aktivierung der neuen Firewall-Regel(n) nicht der Daemon durchgestartet werden muss und somit alle aktiven Verbindungen kurz getrennt werden. Sondern unsere Änderungen können on-the-fly aktiviert oder auch wieder deaktiviert werden.
Damit unsere Clients Verbindungen zu dem geöffneten UDP-Port ntp/123 chrony-Daemons aufbauen können, müssen wir für diese noch Änderungen am Paketfilter firewalld vornehmen.
In folgendem Konfigurationsbeispiel gehen wir von einem Host aus, der zwei Firewall-Zonen hält, einmal die Zone idmz und einmal die Zone intra. in Beiden Zonen öffnen wir nun für die zugehörigen Netze den UDP-Port ntp/123.
Mit Hilfe des Programms firewall-cmd legen wir nun jeweils eine permanente Regel in der beiden Zonen idmz und intra an. Als Source-IP geben geben wir jeweils die Netze unserer Clients an. Genug der Vorrede, mit nachfolgendem Befehl wird der Port 123 geöffnet.
Paketfilter - firewalld
# firewall-cmd --permanent --zone=idmz --add-rich-rule="rule family="ipv4" source address="10.0.0.0/24" port protocol="udp" port="123" \
destination address="10.0.0.110/32" accept"
success
# firewall-cmd --permanent --zone=idmz --add-rich-rule="rule family="ipv6" source address="2003:a:e0d:7603::/64" port protocol="udp" port="123" \
destination address="2003:a:e0d:7603:10::110/64" accept"
success
# firewall-cmd --permanent --zone=intra --add-rich-rule="rule family="ipv4" source address="192.168.0.0/24" port protocol="udp" port="123" \
destination address="192.168.0.110/32" accept"
success
# firewall-cmd --permanent --zone=intra --add-rich-rule="rule family="ipv6" source address="2003:a:e0d:7607::/64" port protocol="udp" port="123" \
destination address="2003:a:e0d:7607:1920:168:0:110/64" accept"
success
Anschliessend können wir den Firewall-Daemon einmal neu laden und anschließend überprüfen, ob die Regeln auch entsprechend unserer Definition, gezogen haben.
# firewall-cmd --reload
success
Werfen wir noch kurz einen Blick in die Zone idmz:
# firewall-cmd --zone=idmz --list-rich-rules
rule family="ipv6" icmp-type name="echo-request" accept rule family="ipv6" source address="2003:a:e0d:7603::/64" destination address="2003:a:e0d:7603:10::110/64" port port="123" protocol="udp" accept rule family="ipv4" source address="10.0.0.0/24" destination address="10.0.0.110/32" port port="123" protocol="udp" accept
Bei Bedarf machen wir das gleiche nun noch mit der Zone intra:
# firewall-cmd --zone=intra --list-rich-rules
rule family="ipv4" source address="10.0.10.0/24" service name="ssh" accept rule family="ipv4" source address="192.168.0.0/24" destination address="192.168.0.110/32" port port="123" protocol="udp" accept rule family="ipv6" source address="2003:a:e0d:7607::/64" service name="ssh" accept rule family="ipv6" source address="2003:a:e0d:7607::/64" destination address="2003:a:e0d:7607:1920:168:0:110/64" port port="123" protocol="udp" accept
Start des Daemon
manueller Start des Daemon
Möchten wir unseren Daemon starten, benutzen wir den folgenden Befehlsaufruf.
# systemctl start chronyd.service
Wollen wir den Status des Chrony-Daemon abfragen nutzen wir den gewohnten Aufruf:
# systemctl status chronyd.service
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2024-02-18 18:26:17 CET; 5s ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Process: 1863 ExecStart=/usr/bin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 1865 (chronyd)
Tasks: 1 (limit: 9510)
Memory: 9.4M (peak: 9.9M)
CPU: 74ms
CGroup: /system.slice/chronyd.service
└─1865 /usr/bin/chronyd
Feb 18 18:26:17 vml000110 systemd[1]: Starting NTP client/server...
Feb 18 18:26:17 vml000110 (chronyd)[1863]: chronyd.service: Referenced but unset environment variable evaluates to an empty string: OPTIONS
Feb 18 18:26:17 vml000110 chronyd[1865]: chronyd version 4.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
Feb 18 18:26:17 vml000110 chronyd[1865]: Frequency 24.000 +/- 0.079 ppm read from /var/lib/chrony/drift
Feb 18 18:26:17 vml000110 chronyd[1865]: Using right/UTC timezone to obtain leap second data
Feb 18 18:26:17 vml000110 systemd[1]: Started NTP client/server.
Feb 18 18:26:22 vml000110 chronyd[1865]: Selected source 136.243.177.133 (pool.ntp.org)
Feb 18 18:26:22 vml000110 chronyd[1865]: System clock TAI offset set to 37 seconds
Zur Anzeige des chronyd spezifischen Protokolle, die der journald-Daemon gesammelt hat, verwenden Sie den Befehl journalctl.
# journalctl -u chronyd
Feb 18 18:26:17 vml000110 systemd[1]: Starting NTP client/server... Feb 18 18:26:17 vml000110 (chronyd)[1863]: chronyd.service: Referenced but unset environment variable evaluates to an empty string: OPTIONS Feb 18 18:26:17 vml000110 chronyd[1865]: chronyd version 4.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG) Feb 18 18:26:17 vml000110 chronyd[1865]: Frequency 24.000 +/- 0.079 ppm read from /var/lib/chrony/drift Feb 18 18:26:17 vml000110 chronyd[1865]: Using right/UTC timezone to obtain leap second data Feb 18 18:26:17 vml000110 systemd[1]: Started NTP client/server. Feb 18 18:26:22 vml000110 chronyd[1865]: Selected source 136.243.177.133 (pool.ntp.org) Feb 18 18:26:22 vml000110 chronyd[1865]: System clock TAI offset set to 37 seconds
automatischer Start des Daemon
Damit der Daemon chrony automatisch bei jedem Systemstart startet, kann die Einrichtung eines Start-Scriptes über folgenden Befehl erreicht werden:
# systemctl enable chronyd.service
ln -s '/usr/lib/systemd/system/chronyd.service' '/etc/systemd/system/multi-user.target.wants/chronyd.service'
Ein Überprüfung ob der Dienst (Daemon)chrony wirklich bei jedem Systemstart automatisch mit gestartet wird, kann durch folgenden Befehl erreicht werden:
# systemctl is-enabled chronyd.service
enabled
Tests
Daemon
Als ersten Test überprüfen wir, ob der Service chronyd geladen und ausgeführt wird. Hierzu benutzen wir folgenden Befehl.
# systemctl status chronyd.service
# systemctl status chronyd.service
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: disabled)
Active: active (running) since Sun 2024-02-18 18:26:17 CET; 5s ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Process: 1863 ExecStart=/usr/bin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 1865 (chronyd)
Tasks: 1 (limit: 9510)
Memory: 9.4M (peak: 9.9M)
CPU: 74ms
CGroup: /system.slice/chronyd.service
└─1865 /usr/bin/chronyd
Feb 18 18:26:17 vml000110 systemd[1]: Starting NTP client/server...
Feb 18 18:26:17 vml000110 (chronyd)[1863]: chronyd.service: Referenced but unset environment variable evaluates to an empty string: OPTIONS
Feb 18 18:26:17 vml000110 chronyd[1865]: chronyd version 4.5 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +SCFILTER +SIGND +ASYNCDNS +NTS +SECHASH +IPV6 -DEBUG)
Feb 18 18:26:17 vml000110 chronyd[1865]: Frequency 24.000 +/- 0.079 ppm read from /var/lib/chrony/drift
Feb 18 18:26:17 vml000110 chronyd[1865]: Using right/UTC timezone to obtain leap second data
Feb 18 18:26:17 vml000110 systemd[1]: Started NTP client/server.
Feb 18 18:26:22 vml000110 chronyd[1865]: Selected source 136.243.177.133 (pool.ntp.org)
Feb 18 18:26:22 vml000110 chronyd[1865]: System clock TAI offset set to 37 seconds
Betreiben wir den chronyd im Client-Modus, wird kein Port 123 bedient - daher wird bei der nachfolgenden Abfrage auch kein geöffneter Port 123 gemeldet.
# ss -tulpn | grep 123
Betreiben wir unseren chrony Daemon im Servermode wird dann natürlich der Port 123 auf den konfigurierten Netzwerkadressen gebunden.
# ss -paunt
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 0.0.0.0:123 0.0.0.0:* users:(("chronyd",pid=1865,fd=7))
udp UNCONN 0 0 127.0.0.1:323 0.0.0.0:* users:(("chronyd",pid=1865,fd=5))
udp UNCONN 0 0 [::]:123 [::]:* users:(("chronyd",pid=1865,fd=8))
udp UNCONN 0 0 [::1]:323 [::]:* users:(("chronyd",pid=1865,fd=6))
Checking chrony Sources
Welche Server vom lokalen Daemon benutzt werden kann mit Hilfe des Befehls chronyc sources abgefragt werden.
# chronyc sources
MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* kronos.mailus.de 3 8 377 91 -106us[ -128us] +/- 57ms
Dieses Beispiel zeigt die Abfrage auf unserem zentralen NTP-Server, den wir gerade eingerichtet haben. Nachfolgendes Beispiel zeigt einen Host, der wiederum unseren eigenen zentralen NTP-Server als Quelle benutzt.
MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* vml000110.idmz.nausch.org 4 6 377 33 +33us[ +15us] +/- 33ms ^+ 10.0.0.110 4 6 377 33 +29us[ +29us] +/- 33ms
Die einzelnen Spalten haben folgende Bedeutung:
- M
Zeigt den Modus der Angezeigten Quelle,- ^ steht für einen NTP-Server,
- = steht für einen Peer-Rechner und
- # steht für eine lokal am Host angeschlossene Referenzuhr.
- S
Zeigt den Status der Zeitquelle an- * bedeutet, der chrony-Daemon hat sich mit der Quelle synchronisiert.
- + die Quelle wird als akzeptabl gewertet, die mit der ausgewählten Quelle kombiniert wird.
- - steht für eine akzeptable Quelle, die aber durch die Kombinationsalgorithmus ausgeschlossen wird.
- ? bedeutet, dass die Verbindung lückenhaft war bzw. abgebrochen ist oder dessen UDP-Pakete nicht alle Tests bestanden haben.
- x definiert eine fehlerhafte Quelle, deren Zeitangaben nicht mit den anderen Quellen nicht im Einklang gebracht werden können.
- ~ steht für eine Quelle mit großen Schwankungen und
- ? Anzeige, dass der Daemon gerade erst gestartet wurde und weniger als 4 Datenpakete empfangen wurden.
- Name/IP address
Zeigt den Namen bzw. die IP-Adresse der Quelle, Referenz-ID oder der lokalen Referenz-Uhr. - Stratum
Anzeige des Stratum-Wertes von der Quelle an Hand der zuletzt empfangenen Datenpakete.- 1 wird angezeigt, wenn der Server über eine lokal angeschlossene Referenzuhr verfügt.
- 2 wird angezeigt, wenn der Daemon sich mit einer Quelle synchronisiert hat, die den Wert Stratum 1 inne hat.
- n Jede weitere Erhöhung des Stratum-Wertes bedeutet, dass ein weiterer Host zwischen dem chrony-Daemon und dem Zeitnormal mit dem Stratum Wert 1 steht.
- Poll
Angabe in welchen Abständen die Uhrzeit turnusmäßig synchronisiert wird. Die Zeitspanne errechnet sich bei einem polling-Wert n = 6 nach (2n) von 26 = 64. Der Wert kann schwanken, je nach dem wie stabil das Zeitnormal verläuft. - Reach
Registerwert (Oktalzahl) der empfangenen Datenpakete. Das Register hat hat 8 bit und wird jeweils beim Empfang bzw. etwaigen Verlusten von Datenpaketen angepasst. Ein Wert von 377 zeigt z.B. an, das die letzten acht empfangenen Datenpakete gültig waren. - LastRx
In dieser Spalte wird angezeigt, wann zuletzt von der genannten Zeitquelle ein Datenpaket empfangen wurde. Ein reiner Zahlenwert steht für die Angabe in Sekunden, sowie die Buchstaben m, h, d oder y jeweils für Minuten, Stunden, Tage bzw. Jahre. Der Wert 10 Jahre steht dafür, dass noch kein gültiges Datenpaket von der Quelle empfangen wurde. - Last sample
Hier wird der Offset zwischen der lokalen Zeit und dem empfangenen NTP-UDP-Paket des Zeitservers angezeigt. Der Wert in den eckigen Klammern zeigt die tatsächlich gemessene Abweichung (Offset). Die Werte werden in den Einheiten ns für Nanosekunden, us für Mikrosekunden, ms für Millisekunden und s für Sekunden angegeben. Die Zahl auf der linken Seite der eckigen Klammern zeigt die ursprünglichen Messwert an, mit dem die Messwerte bis jetzt korrigiert wurden. Die Zahl nach dem +/- Anzeige zeigt die Fehlerspanne bei der Messung. Positive Offsets anzuzeigen, dass die lokale Zeit der NTP-Serverzeit vorausläuft.
Haben wir uns mit chronyc verbunden, können wir uns auch mit der Option -v eine Beschreibung der Spalten abrufen.
# chronyc -a
chrony version 4.5 Copyright (C) 1997-2003, 2007, 2009-2023 Richard P. Curnow and others chrony comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public License version 2 for details. chronyc>
chronyc> sources -v
.-- Source mode '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current best, '+' = combined, '-' = not combined, | / 'x' = may be in error, '~' = too variable, '?' = unusable. || .- xxxx [ yyyy ] +/- zzzz || Reachability register (octal) -. | xxxx = adjusted offset, || Log2(Polling interval) --. | | yyyy = measured offset, || \ | | zzzz = estimated error. || | | \ MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== ^* kronos.mailus.de 3 8 377 47 +135us[ +169us] +/- 37ms
Checking chrony Source Statistics
Den Status unserer Zeitserverquellen fragen wir mit dem Befehl chronyc sourcestats ab.
# chronyc sourcestats
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== kronos.mailus.de 26 16 35m +0.005 0.141 +697ns 107us
Die einzelnen Spalten haben folgende Bedeutung:
- Name / IP-Adresse
Name bzw. die IP-Adresse der Quelle, Referenz-ID oder der lokalen Referenz-Uhr auf den/die sich die folgenden Werte beziehen. - NP
Anzahl der Abtastpunkte (sampling points), die derzeit vom Daemon verwendet werden. Die Driftrate und der Offset werden durch eine lineare Regression der Abtastpunkte geschätzt. - NR
Anzahl der Durchläufe der Restwertberechnungen mit dem gleichen Vorzeichen nach der letzten Regression. Sobald dieser wert unter die Anzahl der Abtastpunkte (sampling points) ist dies ein Anzeichen, dass die Werte nicht mehr optimal linear berechnet werden können. Wird die Anzahl der Durchläufe zu klein, führt chronyd basieren auf alte bekannte Daten eine neu Regression durch, bis der wert wieder in einem akzeptablen Bereich liegt. - Span
Abstand zwischen dem ältesten und neuesten Sample. Wird keine Einheit angegeben, werden Sekunden angezeigt; m steht für Minuten. - Frequency
geschätzte Restfrequenz, die dedr Daemon nutzte (10-6) - Freq Skew
geschätzte Fehlergrenzen des Werts Frequency (10-6). - Offset
geschätzter Offset der Quelle. - Std Dev
geschätzte Standardabweichung der Stichprobe.
Haben wir uns mit chronyc verbunden, können wir uns auch mit der Option -v eine Beschreibung der Spalten abrufen.
# chronyc -a
chrony version 4.5 Copyright (C) 1997-2003, 2007, 2009-2023 Richard P. Curnow and others chrony comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public License version 2 for details. chronyc>
chronyc> sourcestats -v
.- Number of sample points in measurement set.
/ .- Number of residual runs with same sign.
| / .- Length of measurement set (time).
| | / .- Est. clock freq error (ppm).
| | | / .- Est. error in freq.
| | | | / .- Est. offset.
| | | | | | On the -.
| | | | | | samples. \
| | | | | | |
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
==============================================================================
kronos.mailus.de 26 16 35m +0.005 0.141 +1048ns 107us
Checking chrony Tracking
Die Anzeige der System Zeit Informationen fragen wir mit dem Befehl chronyc tracking ab.
# chronyc tracking
Reference ID : 88F3B185 (kronos.mailus.de) Stratum : 4 Ref time (UTC) : Sun Feb 18 18:06:16 2024 System time : 0.000038475 seconds fast of NTP time Last offset : +0.000023120 seconds RMS offset : 0.000039260 seconds Frequency : 23.886 ppm fast Residual freq : +0.003 ppm Skew : 0.136 ppm Root delay : 0.029358303 seconds Root dispersion : 0.018334404 seconds Update interval : 257.0 seconds Leap status : Normal
Die einzelnen Werte haben nachfolgend aufgeführte Bedeutungen:
- Reference ID
Referenz-ID bzw. Name und die IP-Adresse mit dem sich der chrony-Daemon synchronisiert hat. Der Wert 127.127.1.1 zeigt an, dass sich der Daemon nicht mit einer externen NTP-server synchronisiert hat, sondern dass der Daemon im „lokal mode“ befindet, da der Server über eine externe Signalquelle z.B. einer DCF 77 Funkuhr verfügt. - Stratum
Anzeige des Stratum-Wertes von der Quelle an Hand der zuletzt empfangenen Datenpakete.- 1 wird angezeigt, wenn der Server über eine lokal angeschlossene Referenzuhr verfügt.
- 2 wird angezeigt, wenn der Daemon sich mit einer Quelle synchronisiert hat, die den Wert Stratum 1 inne hat.
- n Jede weitere Erhöhung des Stratum-Wertes bedeutet, dass ein weiterer Host zwischen dem chrony-Daemon und dem Zeitnormal mit dem Stratum Wert 1 steht.
- Ref time (UTC)
Uhrzeit (UTC) der Referenz ID, also der Zeit des externen Zeitservers oder der lokalen externen Uhr. - System time
Im normalen Betrieb wird der chrony-Daemon die lokale Zeit nicht in einem Schritt neu stellen, da dies zu ungewollten Effekten führen würde. Chrony word daher zur Anpassung der lokalen Uhrzeit an das externe Ziel durch Veränderungen der Laufgeschwindigkeit der lokalen Uhr anpassen; d.h. die loakel Uhr wird mal schneller oder langsamer als die Uhr des Zeitquelle laufen. Diese Abweichung wird beim Punkt Ref time (UTC) angegeben. - Last offset
Repräsentiert die geschätze Differenz der lokalen Uhr zur externen Quelle. - RMS offset
Dies ist die Anzeige der durchschnittliche Abweichung der lokalen Uhr zur externen Quelle. - Frequency
Abweichung der lokalen Uhrzeit vom Zeitnormal, in der Annahme chronyd würde die Zeit nicht anpassen. Der Wert wird in ppm1) angegeben. - Residual freq
Anzeige der Restfrequenz (residual frequency) für die aktuell ausgewählte Referenzquelle. Der angezeigte Wert spiegelt einen Unterschied zwischen dem, was die Messung von der Referenzquelle vorgibt un der aktuell von chrony-Daemon verwendeten Frequenz wieder. Der Wert wird dabei niemals den Wert 0 anzeigen, da bei der Berechnung der Frequenzwerte Rundungen verwendet werden. Jedes mal wenn der Frequenzwert des Zeitnormals empfangen wurde und die neue Restfrequenz berechnet wurde, wird die geschätzte Genauigkeit dieses neuen Restwertes mit den vorhandenen Werten verglichen und angezeigt. Je genauer die Messungen der Referenzquelle ist und je stabiler die lokale Uhr läuft um so geringer wird der angezeigte Wert und nähert sich im Idealfall dem Wert 0 an. - Skew
Frequenzdrifft in ppm2). - Root delay
Verzögerung durch Laufzeitunterschiede zwischen dem Straum 1 und dem lokalen Server, die durch Laufzeitunterschiede im Netzwerk aufgetreten sind. - Root dispersion
Ungefähre Abweichung (Streuung), bedingt durch statistischen Messschwankungen oder Rundungsdifferenzen, der lokalen Uhrzeit bis hin zur Stratum 1 Quelle. - Update interval
Intervall in Sekunden, in der der Daemon die Uhrzeit spätentens aktualisiert. - Leap status
Sprungstatus der Uhrzeit, die einen der folgenden Werte aufweisen kann:- Normal normaler Betrieb, also alles in Ordnung,
- Insert second Zeit wurde durch Einfügen einer Sekunde verlangsamt,
- Delete second Zeit wurde durch Löschen einer Sekunde beschleunigt, oder
- Not synchronized Zeit konnte noch nicht synchronisiert werden.
Checking chrony Clients
Betreiben wir unseren chrony-Daemon im Server-Mode, können wir uns anzeigen lassen, welcher oder welche Clients sich mit dem Daemon verbunden haben, egal ob via NTP oder zum command/monitoring Port. Hierzu öffnen wir zuerst einmal die chrony-Shell auf unserem Server, auf dem der chrony-Daemon läuft.
# chronyc -a
chrony version 4.5 Copyright (C) 1997-2003, 2007, 2009-2023 Richard P. Curnow and others chrony comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. See the GNU General Public License version 2 for details. chronyc>
Anschliessend fragen wir mit dem Befehl clients ab, welche Clients sich mit dem Server verbunden haben.
chronyc> clients
Hostname NTP Drop Int IntL Last Cmd Drop Int Last =============================================================================== 2003:a:e0d:7603:10::210 39 0 6 - 53 0 0 - - _gateway 39 0 6 - 53 0 0 - -
Die einzelnen Werte haben nachfolgend aufgeführte Bedeutungen:
- Hostname
Hostname oder IP-Adresse des Clients - Client
Anzahl der Verbindungen des Clients im NTP client mode - Peer
Anzahl der Verbindungen des Clients im NTP symmetric active mode - CmdAuth
Anzahl der authentifizierten Steuerpakete die vom Client bis jetzt erfolgreich, d.h. nach dem password-Befehl, abgesetzt wurden. - CmdNorm
Anzahl der nicht authentifizierten Steuerpakete die vom Client bis jetzt abgesetzt wurden. - CmdBad
Anzahl der erfolglosen Versuche Steuerpakete die vom Client bis jetzt abgesetzt wurden. - LstN
Zeit seit dem das letzte NTP Pakete empfangen wurde - LstC
Zeit seit dem das letzte Steuerpaket/Befehl empfangen wurde
Orchestrierung - Installation und Konfiguration des chronyd mit Hilfe von Ansible
Natürlich wird man im Jahr 2024 nicht mehr ernsthaft, manuell Server aufsetzen und betreiben wollen. Vielmehr wird amn auf ein Orchestrierungswerkzeug wie z.B. Ansible zurückgreifen.
Wir werden uns nun nachfolgend sowohl die Client- wie auch die Server-Installation und -konfiguration genauer betrachten.
Installation und Client-Konfiguration
Setzen wir einen neue virtuellen Host unter Arch Linux neu auf, oder wollen wir bei einem bestehenden Host die Konfiguration aktualisieren, verwenden wir wie zuvor schon angeschnitten Ansible als Orchstrierungswerkzeug. So ist sichergestellt dass zum einen all unsere Hosts entsprechend gleich aufgebaut, konfiguriert und betrieben werden.
Für die Konfiguration unserer Hosts verwenden wir eine eigene Rolle chrony_client, die wir dann in einem unserer Playbooks später einfach mit aufrufen werden.
$ tree roles/chrony_client/
roles/chrony_client/ ├── defaults ├── files ├── handlers ├── library ├── lookup_plugins ├── meta ├── module_utils ├── tasks │ ├── chrony.yml │ └── main.yml ├── templates └── vars
Wie wir sehen ist die Rolle durchaus überschaubar, im Task main.yaml verweisen wir lediglich auf den eigentlichen Task chrony-.yml.
$ vim ~/ansible/roles/chrony_client/tasks/main.yml
- roles/chrony_client/tasks/main.yml
--- # Playbook/Rolle zur Konfiguration des NTP-Clients - include_tasks: chrony.yml # Chrony Client installieren und konfigurieren. tags: chrony # ... # YML Ende
Die eigentliche Installation und Konfiguration erfolgt dann im Task chrony.yml.
$ vim ~/ansible/roles/chrony_client/tasks/chrony.yml
- roles/chrony_client/tasks/chrony.yml
--- # YAML Start # SSH Server Configdatei erzeugen und kopieren. - name: "Installation des chrony-Daemons." community.general.pacman: name: chrony state: present - name: "Checken ob es bereits eine Backupdatei der chrony.conf gibt." ansible.builtin.stat: path: /etc/chrony.conf.orig register: check_chrony_config - name: "Backupdatei der chrony.conf Konfigurationsdatei erstellen." ansible.builtin.copy: remote_src: true src: /etc/chrony.conf dest: /etc/chrony.conf.orig owner: root group: root mode: '0644' when: not check_chrony_config.stat.exists - name: "Änderungen an der chrony.conf mit blockinfile vornehmen." ansible.builtin.blockinfile: path: /etc/chrony.conf marker: '# {mark} ANSIBLE MANAGED - DO NOT EDIT BLOCK' insertbefore: BOF block: | # Ansible managed configuration file, do not modify manually! - name: "Änderungen an der chrony.conf mit lineinfile vornehmen." ansible.builtin.lineinfile: dest: /etc/chrony.conf regexp: '{{ item.from }}' line: '{{ item.to }}' state: present backrefs: false with_items: '{{ chrony_config }}' - name: "Sicherstellen, dass der chrony Service reboot(-fest) startet." ansible.builtin.systemd: name: chronyd # state: reloaded enabled: true ... # YML Ende
django