Fixing Server Time Skew - Synchronizing NTP with chrony and timedatectl

Fixing Server Time Skew - Synchronizing NTP with chrony and timedatectl
Reading time: About 12 min Difficulty: Intermediate

Why time skew causes real problems

A few seconds of clock drift can break SSL/TLS certificate validation, Kerberos authentication, log correlation across hosts, and cron scheduling. When time sync fails the failure usually looks like something else entirely — making it one of the more frustrating things to diagnose.

First check (run this now)

timedatectl status

System clock synchronized: yes means you're good. no — follow the steps below.

How to check current time state

timedatectl status gives a full picture in one command: NTP sync status, timezone, and hardware clock state.

timedatectl status

timedatectl status
               Local time: Mon 2026-06-01 10:00:00 JST
           Universal time: Mon 2026-06-01 01:00:00 UTC
                 RTC time: Mon 2026-06-01 01:00:00
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
Field Healthy Needs fixing
System clock synchronized yes no
NTP service active inactive / n/a

Verify system time against UTC

date
date -u

The difference between local time and UTC should match your timezone offset exactly.

Which NTP client is running?

Modern Linux uses one of two NTP clients. Do not run both simultaneously.

Daemon Common on Config file
systemd-timesyncd Ubuntu (lightweight) /etc/systemd/timesyncd.conf
chronyd Ubuntu / RHEL / CentOS (high precision) /etc/chrony.conf

Check which is active:

systemctl status systemd-timesyncd
systemctl status chronyd

Running both chronyd and systemd-timesyncd causes conflicts — neither will sync reliably. Enable only one.

Using chrony to diagnose and fix time skew

Check sync state with chronyc tracking

chronyc tracking
Reference ID    : 133.243.238.163 (ntp.nict.jp)
Stratum         : 2
Ref time (UTC)  : Mon Jun 01 01:00:00 2026
System time     : 0.000123456 seconds fast of NTP time
Last offset     : +0.000123456 seconds
RMS offset      : 0.000012345 seconds
Frequency       : -1.234 ppm fast
Residual freq   : +0.001 ppm
Skew            : 0.123 ppm
Root delay      : 0.012345678 seconds
Root dispersion : 0.000123456 seconds
Update interval : 64.2 seconds
Leap status     : Normal

System time shows the current offset. Anything beyond a few seconds warrants immediate action.

View NTP server list

chronyc sources -v
MS Name/IP address         Stratum Poll Reach LastRx Last sample
^* ntp.nict.jp                   1   6    37    43  -0.123ms[+0.456ms] +/- 12.3ms

^* marks the currently selected server. Many ? or x sources indicate the NTP servers themselves are unreachable.

Force immediate sync with makestep

For large offsets (seconds or minutes), skip the normal gradual slew:

chronyc makestep
200 OK

makestep abruptly jumps the clock forward or back. This creates gaps or overlaps in log timestamps. Confirm the impact before running on production systems.

Install and start chronyd if missing

# Ubuntu
sudo apt install chrony
sudo systemctl enable --now chronyd

# RHEL / CentOS / Rocky Linux
sudo dnf install chrony
sudo systemctl enable --now chronyd

Enable NTP with timedatectl

When NTP sync is inactive (NTP service: inactive), enable it:

sudo timedatectl set-ntp true

Verify:

timedatectl status | grep NTP
NTP service: active

Fix a misconfigured timezone

A wrong timezone is a common cause of apparent time skew:

# Check current timezone
timedatectl status | grep "Time zone"

# Search available zones
timedatectl list-timezones | grep America

# Set timezone
sudo timedatectl set-timezone America/New_York

Configuring systemd-timesyncd

Environments using systemd-timesyncd instead of chrony:

timedatectl show-timesync --all

To change NTP servers, edit /etc/systemd/timesyncd.conf:

[Time]
NTP=0.pool.ntp.org 1.pool.ntp.org
FallbackNTP=2.pool.ntp.org 3.pool.ntp.org

Apply:

sudo systemctl restart systemd-timesyncd

VM and cloud environments

VMs and containers have additional failure modes that hardware servers don't.

Time skew after VM suspend/resume

Suspend/resume can leave the clock far behind. Correct immediately with chronyc makestep, or prevent it by adding a makestep directive to /etc/chrony.conf:

makestep 1.0 3

This tells chrony: if the offset exceeds 1.0 seconds in the first 3 updates, step immediately rather than slewing gradually.

Cloud provider NTP endpoints

Use the provider's internal NTP endpoint for best reliability:

Provider Recommended NTP
AWS 169.254.169.123
Azure time.windows.com
GCP metadata.google.internal

Firewall blocking NTP

NTP uses UDP port 123. If traffic is blocked, sync will silently fail:

# ufw
sudo ufw allow out 123/udp

# firewalld
sudo firewall-cmd --add-service=ntp --permanent
sudo firewall-cmd --reload

Test NTP reachability to a specific server:

chronyc ntpdata <NTP_SERVER_IP>

Summary

  • Start with timedatectl status — the fastest single diagnostic
  • Enable NTP with sudo timedatectl set-ntp true if inactive
  • Use chronyc tracking for offset details and source quality
  • Force immediate correction with chronyc makestep
  • For VMs, add makestep 1.0 3 to /etc/chrony.conf to survive suspend/resume

Next Reading