Time Synchronization with NTP and Chrony

Imagine you are responsible for a dozen Linux servers spread across two data centers. One server handles email, another runs the company's database, and a third processes financial transactions. If their clocks drift apart by even a few seconds, problems cascade. An email sent at 10:05 from Server A might appear to arrive at Server B at 09:59 — that breaks message ordering and makes audits impossible. A scheduled backup that fires at 02:00 on Server C might run at 01:55 on Server D, causing a race condition where both try to lock the same file. This is why every production Linux system must run a time synchronisation service.

The fundamental tool for this job is the Network Time Protocol, or NTP. NTP is an internet protocol — a set of rules that computers follow to communicate — designed specifically to synchronise clocks over a network. It works in a client-server model. The client (your server) sends a request to an NTP server asking, "What time is it?" The server replies with its current timestamp. But the client does not just accept that timestamp blindly. It calculates the network round-trip delay — the time it took for the request to travel to the server and the reply to come back — and uses that to estimate the actual current time at the server. It then adjusts its own system clock gradually, either speeding it up or slowing it down, so that it converges on the correct time. This correction is called slewing. NTP can achieve accuracy within a few milliseconds over the public internet and within microseconds on a local network.

The NTP ecosystem has a hierarchy, called a stratum. At the top, stratum 0 devices are physical clocks — atomic clocks, GPS receivers, or radio clocks — that are inherently accurate. Stratum 1 servers are computers directly connected to a stratum 0 device. Stratum 2 servers sync from stratum 1 servers, stratum 3 from stratum 2, and so on. The higher the stratum number, the further you are from the reference clock, but also the more resilient you are because you can sync from multiple upstream servers. In practice, most organisations run their own internal NTP server at stratum 2 or 3 and point their other machines to it.

For many years, the standard Linux implementation of NTP was a service called ntpd (NTP daemon). A daemon is just a background process that runs continuously. Ntpd works well, but it has limitations. It is designed for servers that are always on and always connected. If you have a laptop that sleeps, a virtual machine that gets suspended and resumed, or a server that loses network connectivity for hours, ntpd takes a long time to re-synchronise after it comes back. It also tends to keep the clock stable rather than correcting big offsets quickly. This is where Chrony enters the picture.

Chrony is a newer, more modern implementation of NTP. It is now the default time synchronisation service on most major Linux distributions, including RHEL 8 and later, CentOS 8, Fedora, and Ubuntu. Chrony consists of two main programs: chronyd, the daemon that runs in the background, and chronyc, a command-line tool that lets you interact with the daemon. Chrony is designed to work well in environments where the network is intermittent, where the system clock drifts rapidly (common on virtual machines that share a physical host), or where you need fast initial synchronisation after boot. It does this by keeping a record of the system's drift rate — how much the clock gains or loses per hour — and using that information to make smarter corrections.

Both ntpd and Chrony use the same underlying NTP protocol, so they can talk to the same time servers. The key differences are in their behaviour and tuning. Chrony is typically more accurate for machines that are not always on, because it learns the drift rate over time and can compensate immediately after a reboot. Ntpd is better suited for servers that remain powered on for months at a time, because it smooths out small variations more gently. For the LFCS exam, you need to know how to install, configure, start, enable, and verify both services. The configuration files are:

Both files follow a similar structure. You define a list of NTP server addresses using the 'server' or 'pool' directive. A pool is a group of servers, often provided by projects like the NTP Pool Project (pool.ntp.org), that rotate through a set of public NTP servers for load balancing. You can also define 'peer' directives if you want machines to synchronise with each other as equals. After editing the configuration file, you restart the service and verify it is working. For Chrony, the verification command is 'chronyc sources -v'. For ntpd, it is 'ntpq -p'.

Another important concept is the local clock fallback. If your server cannot reach any NTP server, you can configure it to use its own internal clock as a last resort. This is done with the 'local stratum 10' directive in chrony.conf or 'server 127.127.1.0' for the legacy NTP. The stratum value is set high (like 10) so that other machines know this source is less reliable.

Security is also a consideration. The NTP protocol can be authenticated to prevent an attacker from sending fake time updates. Chrony supports authentication using a shared key stored in the /etc/chrony.keys file. The LFCS exam may ask you to enable this. Finally, both services can act as a time server for other machines on your network, not just as a client. You configure this by setting the 'allow' directive in chrony.conf to specify which network addresses or subnets are permitted to query your server.

You work as a junior system administrator for a mid-sized e-commerce company. The company runs its online store on a cluster of six Linux web servers, plus two database servers and a load balancer. The compliance officer sends an urgent email: the company's logs show that a security incident on Tuesday at 14:37 UTC was reported, but the logs from three different servers show timestamps of 14:37, 14:39, and 14:35. The auditors cannot reconstruct the sequence of events. You are told to fix time synchronisation across the entire fleet — permanently.

Your first step is to assess what is already running. You SSH into each server and run 'chronyc tracking' and 'systemctl status chronyd'. On one database server, Chrony is not even installed. On another, it is running but pointing to an NTP server that has been decommissioned. On four of the web servers, the older ntpd service is running instead of Chrony. The company wants a standardised approach, so you decide to migrate everything to Chrony.

You start by editing the configuration on a single test server. The /etc/chrony.conf file needs at least three good NTP sources for reliability. You choose three public NTP servers from the NTP Pool Project, and you add one internal server — the company's own stratum 2 server that syncs from a GPS clock. The configuration looks like this: - server 0.pool.ntp.org iburst - server 1.pool.ntp.org iburst - server 2.pool.ntp.org iburst - server ntp.internal.company.local iburst

The 'iburst' option tells Chrony to send a burst of quick requests immediately after startup, so it synchronises faster on boot. You then add an 'allow' directive to let other machines on the internal 10.0.0.0/24 subnet query this server. Finally, you set the local stratum to 10 as a fallback so this server can still respond to queries even if all upstream NTP servers become unreachable.

After restarting chronyd with 'systemctl restart chronyd', you verify with 'chronyc sources -v'. You see that all four sources are reachable and marked with '*' (the current best source) or '+' (acceptable sources). The offset shows less than 2 milliseconds. You test the fallback by temporarily blocking outbound NTP traffic with iptables and then running 'chronyc sources -v' again. The sources show '?' meaning unreachable, but the local clock is being used.

Next, you write an Ansible playbook to deploy this configuration to all remaining servers. You push the same /etc/chrony.conf file to every machine, enable chronyd with 'systemctl enable --now chronyd', and verify the output of 'chronyc tracking' across all hosts. You also configure the firewall to allow NTP traffic (UDP port 123) only from trusted sources.

Finally, you update the company's runbook documentation. You include the commands to check synchronisation status, a procedure for adding a new NTP server, and a troubleshooting section that covers common issues like firewall blocks, incorrect DNS resolution for the NTP hostnames, and the fact that virtual machines often need a different drift handling strategy. The compliance officer signs off after the next audit shows all logs within 50 milliseconds of each other. This is what real-world time management looks like: audit-proofing your infrastructure, one protocol at a time.