Show Table of Contents
17.2. Understanding chrony and Its Configuration
17.2.1. Understanding chronyd and chronyc
The chrony daemon,
chronyd, can be monitored and controlled by the command line utility chronyc. This utility provides a command prompt, which allows entering a number of commands to query the current state of chronyd and make changes to its configuration. By default, chronyd accepts only commands from a local instance of chronyc, but it can be configured to accept monitoring commands also from remote hosts. The remote access should be restricted.
17.2.2. Understanding the chrony Configuration Commands
The default configuration file for
chronyd is /etc/chrony.conf. The -f option can be used to specify an alternate configuration file path. See the chronyd man page for further options. For a complete list of the directives that can be used see http://chrony.tuxfamily.org/manual.html#Configuration-file.
Below is a selection of
chronyd configuration options:
- Comments
- Comments should be preceded by #, %, ; or !
- allow
- Optionally specify a host, subnet, or network from which to allow
NTPconnections to a machine acting asNTPserver. The default is not to allow connections.Examples:
allow 192.0.2.0/24
Use this command to grant access to a specific network.allow 2001:0db8:85a3::8a2e:0370:7334
Use this this command to grant access to anIPv6.
- The UDP port number 123 needs to be open in the firewall in order to allow the client access:
~]#
firewall-cmd --zone=public --add-port=123/udpIf you want to open port 123 permanently, use the--permanentoption:~]#
firewall-cmd --permanent --zone=public --add-port=123/udp - cmdallow
- This is similar to the
allowdirective (see sectionallow), except that it allows control access (rather thanNTPclient access) to a particular subnet or host. (By “control access” is meant that chronyc can be run on those hosts and successfully connect tochronydon this computer.) The syntax is identical. There is also acmddeny alldirective with similar behavior to thecmdallow alldirective. - dumpdir
- Path to the directory to save the measurement history across restarts of
chronyd(assuming no changes are made to the system clock behavior whilst it is not running). If this capability is to be used (via thedumponexitcommand in the configuration file, or thedumpcommand in chronyc), thedumpdircommand should be used to define the directory where the measurement histories are saved. - dumponexit
- If this command is present, it indicates that
chronydshould save the measurement history for each of its time sources recorded whenever the program exits. (See thedumpdircommand above). - hwtimestamp
- The
hwtimestampdirective enables hardware timestamping for extremely accurate synchronization. For more details, seechrony.conf(5)manual page. - local
- The
localkeyword is used to allowchronydto appear synchronized to real time from the viewpoint of clients polling it, even if it has no current synchronization source. This option is normally used on the “master” computer in an isolated network, where several computers are required to synchronize to one another, and the “master” is kept in line with real time by manual input.An example of the command is:local stratum 10
A large value of 10 indicates that the clock is so many hops away from a reference clock that its time is unreliable. If the computer ever has access to another computer which is ultimately synchronized to a reference clock, it will almost certainly be at a stratum less than 10. Therefore, the choice of a high value like 10 for thelocalcommand prevents the machine’s own time from ever being confused with real time, were it ever to leak out to clients that have visibility of real servers. - log
- The
logcommand indicates that certain information is to be logged. It accepts the following options:The log files are written to the directory specified by the- measurements
- This option logs the raw
NTPmeasurements and related information to a file calledmeasurements.log. - statistics
- This option logs information about the regression processing to a file called
statistics.log. - tracking
- This option logs changes to the estimate of the system’s gain or loss rate, and any slews made, to a file called
tracking.log. - rtc
- This option logs information about the system’s real-time clock.
- refclocks
- This option logs the raw and filtered reference clock measurements to a file called
refclocks.log. - tempcomp
- This option logs the temperature measurements and system rate compensations to a file called
tempcomp.log.
logdircommand. An example of the command is:log measurements statistics tracking
- logdir
- This directive allows the directory where log files are written to be specified. An example of the use of this directive is:
logdir /var/log/chrony
- makestep
- Normally
chronydwill 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 may be so far adrift that this slewing process would take a very long time to correct the system clock. This directive forceschronydto step system clock if the adjustment is larger than a threshold value, but only if there were no more clock updates sincechronydwas started than a specified limit (a negative value can be used to disable the limit). This is particularly useful when using reference clock, because theinitstepslewdirective only works withNTPsources.An example of the use of this directive is:makestep 1000 10
This would step the system clock if the adjustment is larger than 1000 seconds, but only in the first ten clock updates. - maxchange
- This directive sets the maximum allowed offset corrected on a clock update. The check is performed only after the specified number of updates to allow a large initial adjustment of the system clock. When an offset larger than the specified maximum occurs, it will be ignored for the specified number of times and then
chronydwill give up and exit (a negative value can be used to never exit). In both cases a message is sent to syslog.An example of the use of this directive is:maxchange 1000 1 2
After the first clock update,chronydwill check the offset on every clock update, it will ignore two adjustments larger than 1000 seconds and exit on another one. - maxupdateskew
- One of
chronyd's tasks is to work out how fast or slow the computer’s clock runs relative to its reference sources. In addition, it computes an estimate of the error bounds around the estimated value. If the range of error is too large, it indicates that the measurements have not settled down yet, and that the estimated gain or loss rate is not very reliable. Themaxupdateskewparameter is the threshold for determining whether an estimate is too unreliable to be used. By default, the threshold is 1000 ppm. The format of the syntax is:maxupdateskew skew-in-ppm
Typical values for skew-in-ppm might be 100 for a dial-up connection to servers over a telephone line, and 5 or 10 for a computer on a LAN. It should be noted that this is not the only means of protection against using unreliable estimates. At all times,chronydkeeps track of both the estimated gain or loss rate, and the error bound on the estimate. When a new estimate is generated following another measurement from one of the sources, a weighted combination algorithm is used to update the master estimate. So ifchronydhas an existing highly-reliable master estimate and a new estimate is generated which has large error bounds, the existing master estimate will dominate in the new master estimate. - minsources
- The
minsourcesdirective sets the minimum number of sources that need to be considered as selectable in the source selection algorithm before the local clock is updated.The format of the syntax is:minsources number-of-sources
By default, number-of-sources is 1. Setting minsources to a larger number can be used to improve the reliability, because multiple sources will need to correspond with each other. - noclientlog
- This directive, which takes no arguments, specifies that client accesses are not to be logged. Normally they are logged, allowing statistics to be reported using the clients command in chronyc.
- reselectdist
- When
chronydselects synchronization source from available sources, it will prefer the one with minimum synchronization distance. However, to avoid frequent reselecting when there are sources with similar distance, a fixed distance is added to the distance for sources that are currently not selected. This can be set with thereselectdistoption. By default, the distance is 100 microseconds.The format of the syntax is:reselectdist dist-in-seconds
- stratumweight
- The
stratumweightdirective sets how much distance should be added per stratum to the synchronization distance whenchronydselects the synchronization source from available sources.The format of the syntax is:stratumweight dist-in-seconds
By default, dist-in-seconds is 1 millisecond. This means that sources with lower stratum are usually preferred to sources with higher stratum even when their distance is significantly worse. Settingstratumweightto 0 makeschronydignore stratum when selecting the source. - rtcfile
- The
rtcfiledirective defines the name of the file in whichchronydcan save parameters associated with tracking the accuracy of the system’s real-time clock (RTC). The format of the syntax is:rtcfile /var/lib/chrony/rtc
chronydsaves information in this file when it exits and when thewritertccommand is issued in chronyc. The information saved is the RTC’s error at some epoch, that epoch (in seconds since January 1 1970), and the rate at which the RTC gains or loses time. Not all real-time clocks are supported as their code is system-specific. Note that if this directive is used then the real-time clock should not be manually adjusted as this would interfere with chrony's need to measure the rate at which the real-time clock drifts if it was adjusted at random intervals. - rtcsync
- The
rtcsyncdirective is present in the/etc/chrony.conffile by default. This will inform the kernel the system clock is kept synchronized and the kernel will update the real-time clock every 11 minutes.
17.2.3. Security with chronyc
Chronyc can access
chronyd in two ways:
- Internet Protocol (IPv4 or IPv6,
- Unix domain socket, which is accessible locally by the
rootor chrony user.
By default, chronyc connects to the Unix domain socket. The default path is
/var/run/chrony/chronyd.sock. If this connection fails, which can happen for example when chronyc is running under a non-root user, chronyc tries to connect to 127.0.0.1 and then ::1.
Only the following monitoring commands, which do not affect the behavior of
chronyd, are allowed from the network:
- activity
- manual list
- rtcdata
- smoothing
- sources
- sourcestats
- tracking
- waitsync
The set of hosts from which
chronyd accepts these commands can be configured with the cmdallow directive in the configuration file of chronyd, 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 responds with a Not authorised error, even if it is from localhost.
Procedure 17.1. Accessing chronyd remotely with chronyc
- Allow access from both IPv4 and IPv6 addresses by adding the following to the
/etc/chrony.conffile:bindcmdaddress 0.0.0.0
orbindcmdaddress :
- Allow commands from the remote IP address, network, or subnet by using the
cmdallowdirective.Example 17.1.
Add the following content to the/etc/chrony.conffile:cmdallow 192.168.1.0/24
- Open port 323 in the firewall to connect from a remote system.
~]#
firewall-cmd --zone=public --add-port=323/udpIf you want to open port 323 permanently, use the--permanent.~]#
firewall-cmd --permanent --zone=public --add-port=323/udp
Note that the
allow directive is for NTP access whereas the cmdallow directive is to enable receiving of remote commands. It is possible to make these changes temporarily using chronyc running locally. Edit the configuration file to make permanent changes.

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.