NTP and chrony: Configuring Time Synchronization on Linux Correctly

1. Why time synchronization on Linux is critical

An accurate system clock looks like a trivial detail at first glance, but it is a prerequisite for a whole range of critical systems. TLS certificates have a validity window that gets checked against the local clock. If the clock drifts by several minutes, the handshake fails even though the certificate is objectively valid. Kerberos authentication typically tolerates only a few minutes of difference before tickets get rejected as invalid. Without reliable time synchronization, this produces hard-to-diagnose errors that at first glance appear to have nothing to do with the clock at all.

The problem becomes even clearer in distributed systems. Database replication, distributed logging, and monitoring correlation all rely on timestamps being comparable across multiple servers. If a web server's clock runs three seconds ahead and the database runs three seconds behind, events during an incident can no longer be reliably placed in the correct order. NTP, the Network Time Protocol, solves exactly this problem by aligning system clocks against a reference time, and chrony is the implementation that handles this task on modern Linux distributions.

2. How NTP works: stratum, offset, and jitter

NTP organizes time sources into a hierarchy of stratum levels. Stratum 0 are the reference clocks themselves, usually atomic clocks or GPS receivers, which are not addressed directly over the network. Stratum 1 are servers directly connected to such a reference clock. Most servers on the internet, including public pool servers, are stratum 2 or 3, because they obtain their time from a stratum 1 server and in turn serve as a source for further clients. Every additional hop potentially increases the uncertainty of the time value, which is why a lower stratum number is generally considered more precise.

Two measurements matter most in daily operation: offset and jitter. Offset describes the currently measured difference between the local clock and the reference time, typically in the millisecond range. Jitter describes how much this measurement varies from request to request, mostly caused by variable network latency. High jitter makes it harder for chrony to reliably estimate the actual drift, which is why chrony statistically filters multiple measurements rather than trusting a single response blindly. Unlike a simple clock correction that lets time jump abruptly, chrony continuously adjusts the rate at which the system clock runs, so applications never experience a jump backward in time.

3. Installing chrony and basic configuration

On most current Debian, Ubuntu, and RHEL distributions, chrony is already preinstalled as the default time service, since it outperforms systemd-timesyncd in more demanding scenarios. If it is not, apt install chrony or dnf install chrony installs the package along with its systemd unit. The central configuration file lives at /etc/chrony/chrony.conf on Debian based systems or /etc/chrony.conf on RHEL based systems. After every change, the service must be restarted with systemctl restart chrony for the new settings to take effect.

A minimal but complete baseline configuration defines at least one NTP source, a directory for the drift file, and basic access restrictions. The drift file stores how fast the local hardware clock runs ahead of or behind the reference time compared to prior measurements, so chrony can start with a good estimate immediately after a restart instead of starting from zero. Without this file, time synchronization needs several minutes after every reboot before a stable correction is found again.

# Install chrony on Debian/Ubuntu
sudo apt update && sudo apt install -y chrony

# Install chrony on RHEL/Rocky/AlmaLinux
sudo dnf install -y chrony

# Enable and start the service
sudo systemctl enable --now chronyd

# Check that the service is active
systemctl status chronyd --no-pager

# Restart after any config change
sudo systemctl restart chronyd

4. chrony versus classic ntpd: why chrony is the standard

The classic ntpd from the reference NTP project was the de facto standard for decades, but it has structural weaknesses that chrony specifically addresses. ntpd typically needs significantly longer to reach a stable synchronization after startup, and it reacts more sluggishly to changes when the network connection is unstable. chrony, by contrast, was designed from the ground up for systems that are not permanently online, such as laptops that keep switching between networks, or virtual machines that wake up after weeks in a suspended state.

Another practical advantage of chrony: it continues to work correctly even when a system is completely offline for a while, and it synchronizes much faster once the connection is restored, compared to ntpd. For servers that are permanently online, the difference may seem minor, but for anything involving intermittent connectivity, including container based workloads, chrony is the more robust choice. For this reason, Debian, Ubuntu, RHEL, and most other major distributions have established chrony as the default package for time synchronization and pushed ntpd into the background.

5. Configuring NTP sources: pools, own servers, fallbacks

The pool directive in chrony.conf tells chrony to use multiple servers from a DNS pool such as pool.ntp.org and automatically pick the most reliable ones. For most standard servers, two to four pool entries from different regions are enough to ensure redundancy. In corporate networks with their own time infrastructure, the server directive is preferable, pointing explicitly to an internal stratum 1 or stratum 2 server without the detour through public pools and the associated outbound firewall exception.

The iburst option after each source considerably speeds up initial synchronization by sending several requests in quick succession at startup instead of waiting for the normal poll interval. For isolated networks without internet access, such as a DMZ, a local hardware clock can be configured as a low priority fallback source, so the system can still hold a plausible, though not perfect, time without an external NTP connection.

# /etc/chrony/chrony.conf

# Public NTP pool with fast initial sync
pool pool.ntp.org iburst

# Internal reference servers (preferred if reachable)
server ntp1.internal.example.com iburst prefer
server ntp2.internal.example.com iburst

# Fallback: local hardware clock if no source is reachable
local stratum 10

# Store drift information across restarts
driftfile /var/lib/chrony/chrony.drift

# Step the clock on the first three updates if the offset is large
makestep 1.0 3

6. Checking synchronization status with chronyc

The command line tool chronyc is the central interface for checking the status of time synchronization. The command chronyc tracking shows the current system offset, the estimated error rate, and whether the system is considered synchronized. The Leap status field is particularly important and should show Normal. A value like Not synchronised means chrony has not yet found a sufficiently reliable source, which can happen right after a restart or during network problems.

The command chronyc sources -v lists all configured time sources along with stratum, reachability, and current offset. An asterisk before a source marks the currently selected reference, a plus sign marks candidates that are also considered plausible. The reachability column shows, as an octal number, which of the last eight requests were answered successfully, a value of 377 means all eight of the last attempts succeeded. Anyone who wants to regularly verify that time synchronization stays stable should integrate this command into a monitoring script instead of only checking it manually.

# Show the current tracking status
chronyc tracking

# List all configured sources with stratum and offset
chronyc sources -v

# Show detailed statistics per source
chronyc sourcestats -v

# Force an immediate resynchronization
sudo chronyc makestep

# Verify NTS is active for a given source (if configured)
chronyc -N authdata

7. Time synchronization in virtual machines and containers

Virtual machines introduce an additional source of error: the virtualized hardware clock does not always run evenly under hypervisor load, especially on overbooked hosts. A snapshot restored hours or days later starts with a massively wrong system time until chrony corrects it. For such cases, a combination of an aggressive makestep value, which immediately jumps the clock for large deviations instead of adjusting slowly, and a short timeout configuration for the first synchronization after boot is recommended.

Containers mostly share the host kernel's system clock and therefore do not need their own chrony process, an additional chrony daemon inside a container would even compete with the host for control of the clock and should be avoided. What matters instead is that the host itself is correctly synchronized, because every container automatically inherits its system time. On cloud instances with a hypervisor provided time service, as in some KVM or Xen setups, it is worth checking whether the hypervisor already injects a time source, to avoid conflicts between two competing synchronization mechanisms.

8. Securing NTP: NTS, access restriction, monitoring

Classic NTP over UDP is unencrypted and unprotected against manipulation, an attacker on the network path could in theory inject forged time responses to trick certificate validation or falsify logs. Network Time Security, or NTS, solves this problem through TLS based authentication of the time source before the actual NTP packets are exchanged. chrony has supported NTS natively since version 4.0, and many major public pool servers, such as those from Cloudflare or Netnod, offer NTS capable endpoints that can be enabled with the server ... nts directive.

In addition to encryption, access to your own chrony service should be kept restrictive if the server itself acts as a time source for other systems on the internal network. The allow directive limits which subnets are permitted to query, while cmdport 0 completely disables remote access to the administrative command interface when it is not needed. For production environments, a monitoring check that regularly evaluates chronyc tracking and raises an alert once the offset crosses a defined threshold is recommended, before dependent systems like TLS or Kerberos are affected.

# /etc/chrony/chrony.conf — hardened configuration

# Use NTS-authenticated public servers
server time.cloudflare.com iburst nts
server nts.netnod.se iburst nts

# Only allow the internal management subnet to query this server
allow 10.0.0.0/24

# Disable remote administrative access entirely
cmdport 0

# Log measurements for later auditing
log tracking measurements statistics
logdir /var/log/chrony

9. chrony, ntpd, and systemd-timesyncd compared

Alongside chrony and classic ntpd, every systemd based distribution also ships systemd-timesyncd, a deliberately minimal SNTP client. The choice between the three options depends heavily on how precise and how failure resistant time synchronization needs to be.

For production servers, especially systems handling TLS termination, database replication, or Kerberos authentication, chrony is the clearly recommended choice because it combines the fastest convergence, the best NTS support, and the lowest resource usage. systemd-timesyncd is suitable for minimal container images where high precision is not needed, but it should never be used for systems that themselves act as a time source for others.

10. Summary

NTP and chrony solve a problem that stays invisible in daily operation until it becomes acute: an incorrect system clock leads to failed TLS handshakes, invalid Kerberos tickets, and unusable log correlation. chrony has become the standard implementation because it converges faster than classic ntpd, handles unstable connectivity more robustly, and offers modern encrypted protection of the time source through NTS. The combination of pool directives for redundancy, iburst for fast initial synchronization, and a maintained drift file forms the foundation of every stable configuration.

For daily operations, chronyc tracking is the most important command to verify that a system is actually synchronized, while chronyc sources -v provides transparency about the sources in use. In virtualized environments, the configuration should be designed for fast correction after snapshot restoration, while production servers should consistently secure their time traffic with NTS and restrictive allow rules.

11. FAQ: NTP and chrony