How to Configure Chrony and systemd-timesyncd for Precision Network Time Protocol Synchronization in Ubuntu

In distributed Linux environments, precise time synchronisation is a fundamental requirement for system stability, cryptographic security, and data consistency. Discrepancies of even a few milliseconds across server nodes can corrupt distributed database consensus (such as in CockroachDB, Cassandra, or etcd), invalidate Kerberos authentication tokens, generate deceptive system monitoring metrics, and trigger TLS certificate verification failures. Ubuntu provides two primary mechanisms for Network Time Protocol (NTP) management: the lightweight, native systemd-timesyncd daemon, and the enterprise-grade chrony NTP suite. Understanding how to select, deploy, configure, and audit these utilities guarantees nanosecond clock accuracy, rapid convergence, and resilient time-drift compensation.

Evaluating Time Synchronisation Architectures

While both solutions synchronise the system clock against remote upstream time servers, their algorithms, resource footprints, and network tolerances differ significantly. The table below delineates the functional differences between systemd-timesyncd and chrony:

Evaluation Metric	systemd-timesyncd	chrony (chronyd)
Protocol Scope	SNTP (Simple Network Time Protocol) client only.	Full NTP v4 client, NTP server, and peer synchronization.
Default Availability	Installed and enabled by default on Ubuntu Desktop & Server.	Available in standard repositories; default on Ubuntu Cloud images.
Clock Adjustment Strategy	Linear slewing; coarse step jumps on large offsets.	Sophisticated frequency slewing; smooth continuous drift tracking.
Network Intermittency Handling	Requires stable, perpetual network connectivity.	Excels on intermittent, high-jitter, or variable-latency connections.
Convergence Speed	Slow; takes hours to stabilize slight frequency drifts.	Extremely rapid; converges within seconds or minutes using iburst.
Hardware Timestamping	Unsupported.	Supported; leverages PTP hardware timestamping on NICs.

Managing the Native systemd-timesyncd Client

For standalone Ubuntu desktop machines or non-critical virtual appliances, the built-in systemd-timesyncd client provides zero-overhead time keeping without installing external packages.

1. Verifying Active Time Status

To inspect your current system clock, hardware RTC, time zone offset, and NTP synchronisation status, execute:

timedatectl status

Ensure that NTP service: active and System clock synchronized: yes are displayed.

2. Configuring Upstream NTP Pools

To direct systemd-timesyncd to custom enterprise or regional NTP servers, edit its configuration file:

sudo nano /etc/systemd/timesyncd.conf

Uncomment and populate the [Time] block with your preferred pool addresses:

[Time]
NTP=0.uk.pool.ntp.org 1.uk.pool.ntp.org
FallbackNTP=ntp.ubuntu.com

Save the file and restart the service to apply modifications:

sudo systemctl restart systemd-timesyncd

Deploying and Configuring Enterprise-Grade Chrony

For database clusters, virtualised hypervisors, and production web fleets, chrony is the recommended standard due to its rapid convergence and ability to smoothly slew the system clock without abrupt backward jumps that break database write logs.

Step 1: Install Chrony and Disable timesyncd

Two NTP daemons cannot manage the system clock concurrently without competing for kernel adjustments. Installing chrony automatically disables systemd-timesyncd:

sudo apt update && sudo apt install -y chrony

Confirm that systemd-timesyncd is inactive and chrony is running:

systemctl status chrony

Step 2: Customising /etc/chrony/chrony.conf

Open the primary configuration file to tune pool parameters and clock stepping rules:

sudo nano /etc/chrony/chrony.conf

Verify and adjust the following foundational directives:

# Specify reliable upstream NTP pools with burst initialisation
pool 2.ubuntu.pool.ntp.org iburst maxsources 4

# Step the clock instead of slewing only if the offset is larger than 1 second,
# but strictly limit this behaviour to the first 3 clock updates upon boot.
makestep 1.0 3

# Synchronise the real-time hardware clock (RTC) automatically
rtcsync

# Store frequency drift metrics across system reboots
driftfile /var/lib/chrony/chrony.drift

# Log tracking measurements for operational audits
logdir /var/log/chrony

Directive analysis:

• iburst: Dispatches an initial burst of four to eight requests to rapidly calculate the upstream server’s frequency offset, converging time within seconds of network boot.
• makestep 1.0 3: Prevents backward time jumps during active operations. If the clock offset exceeds 1 second during initial boot, Chrony steps the clock immediately; once the first three updates complete, it transitions strictly to smooth microsecond slewing.
• rtcsync: Copies the verified kernel system time to the hardware CMOS clock every 11 minutes.

Restart the daemon to commit configuration updates:

sudo systemctl restart chrony

Auditing Time Tracking and Upstream Sources with chronyc

The companion chronyc command-line utility provides rich telemetry into clock performance, frequency drift, and upstream peer health.

1. Inspecting Upstream Time Sources

To inspect active NTP peers, stratum levels, and reachability metrics, run:

chronyc sources -v

In the resulting matrix:

• ^*: Indicates the current best primary synchronisation source.
• ^+: Designates acceptable candidate sources used for statistical averaging.
• ^?: Signifies an unreachable or unresponsive source.
• Stratum: Measures distance from a reference atomic clock (Stratum 1 is directly attached to GPS/atomic clocks; Stratum 2 peers with Stratum 1).

2. Monitoring Real-Time Tracking Precision

To inspect local system clock offset, frequency error, and estimated absolute precision:

chronyc tracking

Examine the System time offset (typically within 0.000050 seconds / 50 microseconds on high-speed networks) and Root dispersion to confirm stable clock discipline.

Troubleshooting Time Synchronization Bottlenecks

When Ubuntu servers experience chronic time drift or fail to communicate with NTP servers, apply these diagnostic checks:

• UDP Port 123 Blocked by Network Firewalls: NTP communicates over UDP port 123. If chronyc sources displays 0 in the Reach column across all upstream servers, enterprise perimeter firewalls or cloud security groups are dropping outbound UDP 123 packets. Verify connectivity using:

  sudo nc -z -v -u 2.ubuntu.pool.ntp.org 123

• Severe Time Drift in Virtual Machines (KVM / VMware): Virtualised guest operating systems frequently experience clock drift due to CPU oversubscription or host sleep cycles. Enable the hypervisor clock source driver (such as kvm-clock) and ensure Chrony’s makestep directive is configured to compensate for suspended VM wake events.
• Clock Stepping Breaking Database Transactions: If financial ledgers or log aggregators fail due to backward time jumps, remove the makestep directive entirely from /etc/chrony/chrony.conf. Chrony will exclusively slew the clock forward or backward at a gradual rate (maximum 100,000 parts per million), guaranteeing monotonic time progression.