Chapter 28. Using Chrony
The following sections describe how to install, start, and stop
chronyd, and how to check if
chrony is synchronized. Sections also describe how to manually adjust System Clock.
28.1. Managing chrony
The following procedure describes how to install, start, stop, and check the status of
The chrony suite is installed by default on Red Hat Enterprise Linux. To ensure that it is, run the following command as
# dnf install chrony
The default location for the chrony daemon is
/usr/sbin/chronyd. The command line utility will be installed to
To check the status of
chronyd, issue the following command:
systemctl status chronydchronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled) Active: active (running) since Wed 2013-06-12 22:23:16 CEST; 11h ago
chronyd, issue the following command as
# systemctl start chronyd
chronydstarts automatically at system start, issue the following command as
# systemctl enable chronyd
chronyd, issue the following command as
# systemctl stop chronyd
chronydfrom starting automatically at system start, issue the following command as
# systemctl disable chronyd
28.2. Checking if chrony is synchronized
The following procedure describes how to check if chrony is synchronized with the use of the
To check chrony tracking, issue the following command:
chronyc trackingReference ID : CB00710F (foo.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 sources command displays information about the current time sources that
chronydis accessing. To check chrony sources, issue the following command:
$ chronyc sources 210 Number of sources = 3 MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* GPS0 0 4 377 11 -479ns[ -621ns] /- 134ns ^? a.b.c 2 6 377 23 -923us[ -924us] +/- 43ms ^ d.e.f 1 6 377 21 -2629us[-2619us] +/- 86ms
The optional argument -v can be specified, meaning verbose. In this case, extra caption lines are shown as a reminder of the meanings of the columns.
sourcestatscommand displays information about the drift rate and offset estimation process for each of the sources currently being examined by
chronyd. To check chrony source statistics, issue the following command:
chronyc sourcestats210 Number of sources = 1 Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev =============================================================================== abc.def.ghi 11 5 46m -0.001 0.045 1us 25us
The optional argument
-vcan be specified, meaning verbose. In this case, extra caption lines are shown as a reminder of the meanings of the columns.
28.3. Manually adjusting the System Clock
The following procedure describes how to manually adjust the System Clock.
To step the system clock immediately, bypassing any adjustments in progress by slewing, issue the following command as
# chronyc makestep
rtcfile directive is used, the real-time clock should not be manually adjusted. Random adjustments would interfere with chrony's need to measure the rate at which the real-time clock drifts.
28.4. Setting up chrony for a system in an isolated network
For a network that is never connected to the Internet, one computer is selected to be the master timeserver. The other computers are either direct clients of the master, or clients of clients. On the master, the drift file must be manually set with the average rate of drift of the system clock. If the master is rebooted, it will obtain the time from surrounding systems and calculate an average to set its system clock. Thereafter it resumes applying adjustments based on the drift file. The drift file will be updated automatically when the
settime command is used.
The following procedure describes how to set up chrony for asystem in an isolated network.
On the system selected to be the master, using a text editor running as
driftfile /var/lib/chrony/drift commandkey 1 keyfile /etc/chrony.keys initstepslew 10 client1 client3 client6 local stratum 8 manual allow 192.0.2.0
192.0.2.0is the network or subnet address from which the clients are allowed to connect.
On the systems selected to be direct clients of the master, using a text editor running as
root, edit the
server master driftfile /var/lib/chrony/drift logdir /var/log/chrony log measurements statistics tracking keyfile /etc/chrony.keys commandkey 24 local stratum 10 initstepslew 20 master allow 192.0.2.123
192.0.2.123is the address of the master, and
masteris the host name of the master. Clients with this configuration will resynchronize the master if it restarts.
On the client systems which are not to be direct clients of the master, the
/etc/chrony.conf file should be the same except that the
allow directives should be omitted.
In an isolated network, you can also use the
local directive that enables a local reference mode, which allows
chronyd operating as an
NTP server to appear synchronized to real time, even when it was never synchronized or the last update of the clock happened a long time ago.
To allow multiple servers in the network to use the same local configuration and to be synchronized to one another, without confusing clients that poll more than one server, use the
orphan option of the
local directive which enables the orphan mode. Each server needs to be configured to poll all other servers with
local. This ensures that only the server with the smallest reference ID has the local reference active and other servers are synchronized to it. When the server fails, another one will take over.
28.5. Configuring remote monitoring access
chronyc can access
chronyd in two ways:
- Internet Protocol, IPv4 or IPv6.
Unix domain socket, which is accessible locally by the
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:
- manual list
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.
The following procedure describes how to access chronyd remotely with chronyc.
Allow access from both IPv4 and IPv6 addresses by adding the following to the
Allow commands from the remote IP address, network, or subnet by using the
Add the following content to the
Open port 323 in the firewall to connect from a remote system:
# firewall-cmd --zone=public --add-port=323/udp
Optionally, you can open port 323 permanently using the
# firewall-cmd --permanent --zone=public --add-port=323/udp
If you opened port 323 permanently, reload the firewall configuration:
28.6. Managing time synchronization using RHEL System Roles
You can manage time synchronization on multiple target machines using the
timesync role. The
timesync role installs and configures an NTP or PTP implementation to operate as an NTP client or PTP slave in order to synchronize the system clock with NTP servers or grandmasters in PTP domains.
timesync role replaces the configuration of the given or detected provider service on the managed host. Previous settings are lost, even if they are not specified in the role variables. The only preserved setting is the choice of provider if the
timesync_ntp_provider variable is not defined.
The following example shows how to apply the
timesync role in a situation with just one pool of servers.
Example 28.1. An example playbook applying the timesync role for a single pool of servers
--- - hosts: timesync-test vars: timesync_ntp_servers: - hostname: 2.rhel.pool.ntp.org pool: yes iburst: yes roles: - rhel-system-roles.timesync
For a detailed reference on
timesync role variables, install the
rhel-system-roles package, and see the
README.html files in the
28.7. Additional resources
- Frequently Asked Questions