Linux · high · Networking, DNS & SSH

Clock drift and time synchronisation failures

The clock is wrong and nothing is correcting it — or two time daemons are fighting over it.

What you see

Certificate errors, Kerberos failures, log timestamps that make no sense, or a cluster node evicted for being out of sync.

What is actually wrong

More than one time service installed, an NTP source that is unreachable through the firewall, or a virtual machine whose host is also correcting the clock.

Codes and articles

chronydntpdsystemd-timesyncdclock skew too greatTime not synchronisedKRB_AP_ERR_SKEW

Fixes (2)

Get chrony synchronised and keep it there

Root shell20 minuteslow riskreversible

chrony is the intended daemon.

Check the current state and the sources.
Shell
```
chronyc trackingchronyc sources -v
```
The Leap status line in tracking says whether the clock is actually disciplined. A machine can be running chronyd with a wrong clock for weeks and nothing else will tell you.

Make sure no other time service is running.

Shell

systemctl is-active systemd-timesyncd ntpd chronyd 2>/dev/null

Disable the ones you are not using.

Shell

sudo systemctl disable --now systemd-timesyncdsudo systemctl enable --now chronyd

Check UDP 123 is reachable outbound — a firewall blocking it is the usual cause of sources that never reach a reachable state.
Shell
```
sudo chronyc sourcessudo ss -unp | grep 123
```
Step the clock immediately if it is far out. Chrony slews small differences and refuses to slew large ones.
Shell
```
sudo chronyc makestep
```
A machine more than a few minutes out will never converge by slewing, because the correction rate is deliberately gentle. makestep jumps it, which is safe here and is what the machine needs before Kerberos or TLS will work.
On a domain-joined machine, point chrony at the domain controllers rather than public pools.

Confirm it workedchronyc tracking shows a small offset and a leap status of Normal.

Shell

chronyc tracking | grep -E 'Leap|System time|Stratum'timedatectl status

If you need to undo itRe-enable the previous daemon if this was the wrong choice for the environment.

Configure systemd-timesyncd correctly

Root shell15 minuteslow riskreversible

The lightweight systemd client is the intended one — appropriate for clients, not for servers that need to serve time.

Check the state.

Shell

timedatectl statussystemctl status systemd-timesyncd --no-pager

Enable network time synchronisation.
Shell
```
sudo timedatectl set-ntp true
```

Set the servers in a drop-in rather than editing the main file.

Shell

sudo mkdir -p /etc/systemd/timesyncd.conf.dprintf '[Time]\nNTP=dc01.example.local dc02.example.local\nFallbackNTP=ntp.ubuntu.com\n' | sudo tee /etc/systemd/timesyncd.conf.d/10-servers.confsudo systemctl restart systemd-timesyncd

A drop-in survives a package upgrade; an edit to the shipped file gets prompted about or silently replaced.

Set the time zone explicitly rather than relying on the installer default.
Shell
```
sudo timedatectl set-timezone Europe/London
```
For a virtual machine, decide whether the host or the guest owns the clock. Both correcting it produces a sawtooth that neither will fix.

Confirm it workedtimedatectl reports System clock synchronized: yes.

Shell

timedatectl statustimedatectl show-timesync --all | head -20

If you need to undo itsudo timedatectl set-ntp false disables it; remove the drop-in file to revert the servers.

Related faults

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.