The Time Synchronization Problem
In a modern enterprise datacenter, absolute time synchronization across Linux servers is not a luxury; it is a critical security requirement. If a web server and a database server have a clock discrepancy of just 5 seconds, Kerberos authentication tickets will be violently rejected, distributed database transactions (like Cassandra or MongoDB) will suffer from catastrophic write conflicts, and correlating security logs during a forensic audit will be mathematically impossible.
Historically, Linux administrators relied on the classic ntpd daemon to sync clocks with the internet. However, ntpd is notoriously slow; it can take hours to slowly step a heavily drifted clock back into alignment to avoid disrupting running applications.
To solve this, modern Linux distributions (RHEL, Ubuntu, Debian) have transitioned to chrony. Chrony is a highly advanced, ultra-fast implementation of the Network Time Protocol (NTP). It uses complex algorithms to rapidly adjust the clock frequency of the Linux kernel, correcting a 10-minute drift in a matter of seconds without causing the sudden, disruptive “time jumps” that crash databases. Furthermore, chrony works perfectly in environments with intermittent network connectivity (like virtual machines pausing and resuming).
Step 1: Installing the Chrony Daemon
First, verify that the classic ntpd or systemd-timesyncd services are stopped to prevent them from fighting over the kernel clock.
On Ubuntu/Debian:
sudo systemctl disable --now systemd-timesyncd
sudo apt-get update
sudo apt-get install chrony
On RHEL/CentOS/Rocky Linux:
sudo dnf install chrony
Step 2: Configuring the Upstream Servers
You must configure chrony to poll highly accurate upstream servers. If you are in AWS or Google Cloud, you should use their internal stratum-1 time servers. Otherwise, use the public pool.
Edit the main configuration file:
sudo nano /etc/chrony/chrony.conf
(Note: On RHEL-based systems, the path is /etc/chrony.conf).
Locate the pool or server directives and replace them with the following optimal configuration:
# Use the global NTP pool, utilizing the 'iburst' flag to rapidly establish initial sync
pool 2.pool.ntp.org iburst
# Allow chrony to step the clock (jump) IF the drift is greater than 1 second,
# but ONLY during the first 3 clock updates after the daemon starts.
# After that, it must smoothly slew the clock to protect databases.
makestep 1.0 3
# Record the rate at which the hardware clock gains/loses time
driftfile /var/lib/chrony/chrony.drift
# Enable hardware timestamping on supported network cards for microsecond accuracy
hwtimestamp *
# Enable kernel synchronization of the real-time clock (RTC)
rtcsync
Step 3: Creating a Local NTP Server (Optional)
If you are configuring a master server that other servers in your private LAN will sync against (to save internet bandwidth and reduce latency), you must explicitly allow them in the config.
Add this line to chrony.conf to allow the 10.50.0.0/16 subnet to query this server:
allow 10.50.0.0/16
Step 4: Applying and Verifying the Configuration
Save the file and restart the daemon to apply the new algorithmic settings.
sudo systemctl restart chronyd
sudo systemctl enable chronyd
Now, you must verify that the daemon successfully negotiated a cryptographic connection with the upstream servers and successfully disciplined the Linux kernel clock.
Execute the tracking command:
chronyc tracking
Look at the output. The Reference ID should display an IP address (meaning it is synced). The System time metric will tell you exactly how far off the clock is right now (e.g., 0.000000123 seconds slow of NTP time).
To see the exact latency and polling status of your upstream servers, run:
chronyc sources -v
Look for the ^* symbol next to one of the IP addresses. The asterisk means chrony has mathematically selected that specific server as the absolute best source of truth, and your Linux server is now synchronized with microsecond precision.