Time Sync Done Right: chrony 4.5 on a Server Where Clock Drift Breaks Things

When a server’s clock drifts, the failures rarely say “the clock is wrong.” They say the TLS certificate is not yet valid, the one-time password is rejected, the Kerberos ticket is out of skew, or the logs from two hosts cannot be lined up at all.

Time is one of those dependencies nobody notices until it fails, and when it fails it fails obliquely. A few seconds of drift is enough to break a mutual-TLS handshake, invalidate a token whose expiry you are checking to the second, or make an incident timeline useless because host A and host B disagree about when “now” was. On a laptop this barely matters. On a server that authenticates users, signs requests, or feeds a log pipeline a supervisor might later inspect, it matters a great deal. This is how to set up chrony 4.5 as the time client on Ubuntu 24.04 and — the part most guides skip — how to confirm it is genuinely in sync rather than assume it.

Why timesyncd is fine for laptops and wrong for servers

Ubuntu ships with systemd-timesyncd enabled by default. It is a lightweight SNTP client: it queries a time server, nudges the clock, and moves on. For a laptop that sleeps, wakes and roams between networks, that is entirely adequate. What it does not do is discipline the clock properly. It talks to one server at a time, it does not measure or correct the drift rate of the local oscillator, and it gives you almost nothing to inspect when you need to prove the machine’s time is correct.

chrony is a full NTP implementation. It polls several sources at once, discards the ones that disagree, models the clock’s systematic drift so accuracy holds up between polls and across network outages, and — crucially — exposes a detailed view of what it is doing. For a server that must stay precise, and be seen to stay precise, that difference is the whole point. The same discipline that makes a JWT expiry check trustworthy is the discipline chrony provides and timesyncd does not.

Installing chrony and standing timesyncd down

Installing the package is enough to hand over control. On Ubuntu, the chrony package deactivates systemd-timesyncd as part of its post-install step — the two must not run at once, because two daemons fighting over the same clock is worse than neither. Confirm the handover afterwards rather than trust it.

sudo apt update
sudo apt install chrony

# chrony's install disables timesyncd; verify it is gone
systemctl status systemd-timesyncd --no-pager
#   Active: inactive (dead)

# and that chrony is running
systemctl status chrony --no-pager

If systemd-timesyncd is still shown as active, stop and mask it explicitly with sudo systemctl disable --now systemd-timesyncd before going further.

A chrony.conf that behaves on a server

The configuration lives at /etc/chrony/chrony.conf on Ubuntu. The following is a complete, working file for a server that should keep precise time and, optionally, serve it to a trusted local subnet. Comments are inline.

# /etc/chrony/chrony.conf

# Use a pool of servers, not one. iburst sends a rapid initial
# burst so the first sync happens in seconds, not minutes.
pool ntp.ubuntu.com        iburst maxsources 4
pool 0.ubuntu.pool.ntp.org iburst maxsources 1
pool 1.ubuntu.pool.ntp.org iburst maxsources 1

# Record the measured drift of this machine's oscillator so
# accuracy survives reboots and network gaps.
driftfile /var/lib/chrony/chrony.drift

# Step the clock (jump it) rather than slew (ease it) if the
# offset exceeds 1 second, but only for the first 3 updates.
# This fixes a large initial offset instantly at start-up, then
# never jumps again -- steps break monotonic clocks mid-run.
makestep 1.0 3

# Keep the hardware (RTC) clock in step with the system clock.
rtcsync

# Serve time to a trusted subnet. OMIT this line entirely on a
# pure client -- an open NTP server is an amplification risk.
# allow 192.168.10.0/24

# Log tracking, measurements and statistics for later inspection.
logdir /var/log/chrony

Two decisions carry most of the weight. The makestep line is what saves you when a machine boots with a badly wrong clock — a fresh VM, a box that has been powered off for a week. Without it, chrony would slew a large offset gradually and the server would sit misaligned for a long time, breaking exactly the handshakes and token checks you care about. With makestep 1.0 3 it jumps straight to correct at start-up, then reverts to smooth slewing so it never yanks the clock backwards under a running process. The allow line turns the client into a server for the named subnet; leave it commented out unless you actually need to serve time, because an NTP server exposed to the internet can be abused for reflection attacks.

Apply the configuration with a restart:

sudo systemctl restart chrony

Proving it is actually in sync

This is the step that separates a working setup from a hopeful one. Two commands tell you almost everything.

chronyc tracking

Read three fields. Reference ID should name a real upstream server, not 00000000 — a zero reference means chrony has not locked onto anything. Leap status should read Normal; anything else (Not synchronised) means it is not yet trusted. System time shows the current offset from true time — you want this measured in milliseconds or microseconds, not seconds.

chronyc sources -v

The -v flag prints a legend for the state column. The source chrony is currently synchronised to is marked with an asterisk (*); candidate sources being combined show a plus (+); a question mark (?) is unreachable and a minus (-) has been rejected as an outlier. If no line carries an asterisk after a minute or two, the server is not in sync no matter what the other output implies. For a one-line health check in a monitoring probe, chronyc tracking | grep 'Leap status' is a reasonable signal.

Where this pays off

Synchronised clocks are the quiet precondition under a lot of things that are hard to debug when they go wrong. Log correlation across hosts is only meaningful if the timestamps agree — the moment two servers disagree by seconds, an incident timeline stops being evidence, and metrics like the ones behind MTTR and change-failure rate quietly lose their meaning. Deduplication windows in a retry path, such as the ones behind idempotency keys, assume the clock is honest. TOTP, Kerberos and short-lived certificates fail closed when it is not.

timesyncd will keep a laptop roughly right and you will never think about it. A server that authenticates, signs or logs deserves better than roughly right — and chrony is the difference between assuming the clock is correct and being able to show it.