How to Install and Configure Chrony

Network Time Protocol

It is essential to keep the correct time on a server. This is especially true when it comes to processing financial transactions or other vital functions which need to be handled in a specific order. Using the Network Time Protocol (or NTP), computers can synchronize their internal clock times with the internet standard reference clocks. In essence, NTP is a hierarchy of servers. The higher the Stratum number of a server, the more accurate the timing is and the lower the Stratum number of a server is, the lower the accuracy and time stability. Stratus are defined by the distance from the initial reference clock.

• Stratum 0 consists of atomic clocks, GPS satellites, and the “national time and frequency transmission” radio receivers that are tuned to receive the signals broadcast by an atomic clock. They do not directly connect to any devices to provide time synchronization.
• Stratum 1 are the primary servers which are directly connected to Stratum 0 servers and distribute the time to Stratum 2 servers and below. A group of Stratum 0 and Stratum 1 servers are considered NTP Servers. 
• A group of Stratum 2 level servers are considered NTP Peers and can share with each other and the Stratum’s below. Stratum 2 servers are publicly available for anyone to connect to, and they provide time to stratum 3 servers, and so on further down the hierarchy.
• Stratum 3 servers and below, going down to Stratum 15 servers, distribute time as needed to the levels beneath them. Stratum 15 is the lowest Stratum.

Chrony

To pull the correct time from a remote NTP server, a local server needs to use an NTP client. Chrony is one such client. Chrony an excellent choice for this purpose because it is designed to function well under various conditions, such as intermittent and/or heavily congested network connections or other detrimental conditions. Chrony synchronizes the systems internal clock time with higher Stratum NTP servers, reference clock, or the computer's real-time clock at boot time. It can also be manually synchronized with the input by using a wristwatch and keyboard. This is method of synchronization not the most accurate and is actively discouraged. 

Typically, the accuracy between two synchronized machines is within a few milliseconds on a LAN. Chrony consists of two main systems, chronyc, and chronyd. 

• Chronyc is a command-line interface to monitor chronyd’s performance and make changes if necessary.
• Chronyd is the daemon which starts and enables the chrony NTP service and monitors the time and status of the time server while running in the background. 

The time NTP server that chronyd monitors is defined within the chrony.conf file. The Chronyd systems primary function is to obtain the correct time from one of the main NTP server sources. In case the server time is not accurate, chronyd will change the system clock accordingly. 

Installing and Enabling Chrony

Chrony can be installed using the following commands (depending on the operating system).

On a Centos/RHEL server, Chrony can be installed using yum or dnf.

[root@host ~]# yum install chrony
[root@host ~]# dnf install chrony

On a Debian/Ubuntu based system, Chrony can be installed using apt.

[root@host ~]# apt install chrony

Once chrony is installed, we need to start and enable the daemon so that it starts automatically when the server boots up. The commands to accomplish this are as follows.

[root@host ~]# systemctl start chronyd
[root@host ~]# systemctl enable chronyd

In order to check the status of the daemon, we can use the systemctl command.

[root@host ~]# systemctl status chronyd

As an aside, Chrony itself uses the Fedora NTP pool, while CentOS and RHEL have their own unique NTP server pools.

Configuration file

The configuration file for Chrony is located in the /etc/chrony.conf file, and the default file as installed does not require any modification in order for Chrony to work correctly as a client. Here is a typical example of a RedHat chrony.conf file

# Use public servers from the pool.ntp.org project.

# Please consider joining the pool (http://www.pool.ntp.org/join.html).
pool 2.fedora.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).

# Enable hardware timestamping on all interfaces that support it.

#hwtimestamp *

# Increase the minimum number of selectable sources required to adjust

# the system clock.

#minsources 2

# Allow NTP client access from local network.

#allow 192.168.0.0/16

# Serve time even if not synchronized to a time source.

#local stratum 10

# Specify file containing keys for NTP authentication.
keyfile /etc/chrony.keys

# Get TAI-UTC offset and leap seconds from the system tz database.
leapsectz right/UTC

# Specify directory for log files.
logdir /var/log/chrony

# Select which information is logged.

#log measurements statistics tracking

The first directive specified in the configuration file is the list of NTP server pools that the computer will use for synchronization. On a CentOS and RHEL systems the default list would contain the following servers:

• server 0.centos.pool.ntp.org iburst
• server 1.centos.pool.ntp.org iburst
• server 2.centos.pool.ntp.org iburst
• server 3.centos.pool.ntp.org iburst

Apart from the list of servers, the configuration file includes some other information, such as makestep, driftfile, logdir, keyfile, etc.

Verifying Chrony Synchronization

It is possible to synchronize time with an NTP server manually with the following command:

[root@host ~]# chronyd -q ‘server {ntp_server_name} iburst’

Taking the list of NTP server pools mentioned above as an example, the command to synchronize time with the specified NTP server would look like this:

[root@host ~]# chronyd -q 'server 0.centos.pool.ntp.org iburst'

We can also immediately step, or start anew, the system clock while ignoring currently running applications and adjustments, by running the following command:

[root@host ~]# chronyc -a makestep

To verify whether the server’s time is synchronized using Chrony, we can use the command chronyc tracking. The output of this command would show the information as seen in the code below.

root@host [~]# chronyc tracking
Reference ID    : 32CDF416 (ntp3.doctor.com)
Stratum         : 3
Ref time (UTC)  : Fri Apr 03 18:51:09 2020
System time     : 0.001277962 seconds fast of NTP time
Last offset     : +0.001406281 seconds
RMS offset      : 0.001406281 seconds
Frequency       : 18.132 ppm fast
Residual freq   : +0.000 ppm
Skew            : 25.616 ppm
Root delay      : 0.024071140 seconds
Root dispersion : 0.020099793 seconds
Update interval : 65.6 seconds
Leap status     : Normal
root@host [~]#

For reference, here is a breakdown of the values above and their meaning.

• Reference ID is the value indicates the name and ID of the NTP server to which the system’s time is currently synchronized. 
• Stratum specifies the number of hops in servers level to the NTP hierarchy. 
• Ref time is the time per UTC when the last measurement from the reference source was processed.
• System time denotes the amount of delay in a systems clock from a synchronized server.
• Last offset is the estimated time offset since the last clock update.
• RMS Offset denotes the long-term average of the time offset
• Frequency is the value the servers clock would be off if chronyd was not correcting it. This value is measured in ppm (parts per million)
• Residual freq indicates the measurement of difference in between the next-level Stratum source and the current frequency being used.
• Skew is the estimate variance of error in the frequency measured in parts per million
• Root delay is the total time of delay within the network path to the higher level stratum computer from which the local server is being synced.
• Root dispersion is part of the equation that calculates the value derived from the root delay and root dispersion as reported by the tracking command
• Update interval is the distance between the previous two clock updates.
• Leap status is the value which can have one of the following settings
  • normal
  • insert second
  • delete second
  • not synchronized. 

The ‘System Time' from the 'chronyc tracking' command is the difference between the chronyd's estimate of the current true time and the system time. This difference together with root delay and dispersion gives you the estimated maximum error from UTC according to the NTP rfc info. 

The delta and epsilon statistics are accumulated at each stratum level from the reference clock to produce the:

root delay (DELTA) and root dispersion (EPSILON) statistics or abs(System_time) + Root_delay / 2 + Root_dispersion <= target

In order to obtain the information about the current time sources chronyd is using, we can run the command chronyc sources and will supply the example output we see in the code below.

root@host [~]# chronyc sources
210 Number of sources = 4
MS Name/IP address         Stratum Poll Reach LastRx Last sample
================================================================
^+ 134.209.141.224     2 6 377 307 +7645us [+7686us] +/- 72ms
^* ntp3.doctor.com     2 7 377 50  +1520us [+1493us] +/- 31ms
^+ anaheim.capsaic.in  2 7 377 114 +293us  [+256us]  +/- 62ms
^+ mis.wci.com         2 7 377 113 -11ms   [-11ms]   +/- 77ms
root@host [~]#

The symbols next to the NTP servers indicate the following information.

• (*) These are the selected sources to which chronyd is currently synchronized 
• (+) These are acceptable sources that are combined with the selected source 
• (-) These are the acceptable sources that are excluded 

Furthermore, we can list the information about drift speed as well as the offset estimation of each source used by chronyd by running the command chronyc sourcestats.

Conclusion

Overall, chrony is an excellent timekeeping resource we can implement on our servers. As we can see from the above information, the degree to which we can delve into the Network Time Protocol (Version 4) and the Protocol and Algorithms Specification included let us come within milliseconds of the atomic clock that is based on the ground-state hyperfine transition frequency of the caesium-133 atom on which our current structure of time keeping is established.

Learn More!

Our level 3 system administrators are standing by to assist with setting this software up for you should you have any issues.

Simply give us a call at 800.580.4985, or open a chat or ticket with us to speak with one of our knowledgeable Linux technicians or an experienced Hosting Advisors to learn how you can take advantage of this technology today!