Linux chrony NTP Sync Troubleshooting with chronyc

Time is the dependency nobody notices until Kerberos, TLS certificates, distributed databases or log correlation break. Chrony is the modern replacement for ntpd on most distributions: it synchronises faster, copes with intermittent connectivity and VMs better, and exposes its state through chronyc. This article is the practical loop for diagnosing a host whose clock is wrong - reading the tracking output, understanding source state characters, and choosing between slewing and stepping.

A sane minimal configuration

pool pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1 3
rtcsync

iburst makes the first measurements happen quickly instead of over several minutes. driftfile remembers the clock's rate error so accuracy returns fast after reboot. makestep 1 3 allows chronyd to step the clock if it is more than one second off during the first three updates, and afterwards it only slews - the correct behaviour for servers, because a large backwards step can confuse applications. If you do not need chronyc or only want root to use it, add cmdport 0 to close the command sockets.

Reading chronyc output

# chronyc tracking
Reference ID    : C0A87B01 (ntp1.example.net)
Stratum         : 3
Ref time (UTC)  : Thu Sep 17 00:41:22 2026
System time     : 0.000114 seconds slow of NTP time
Last offset     : -0.000021 seconds
RMS offset      : 0.000344 seconds
Frequency       : 12.443 ppm slow
Residual freq   : +0.006 ppm
Skew            : 0.031 ppm
Root delay      : 0.021445 seconds
Root dispersion : 0.000982 seconds
Leap status     : Normal

What matters: Leap status must read Normal (anything else means the clock is not trusted); System time is the current error; Frequency and Skew tell you whether the local oscillator is being learned or is drifting wildly; and a large Root delay points at a slow network path or a poor upstream server. Last offset near zero with a healthy Frequency is a well-behaved host.

Source health: the state characters

# chronyc sources -v
  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unreachable.
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp1.example.net               2   6   377    34    -21us[  -18us] +/-  112us
^+ ntp2.example.net               2   6   377    21   +104us[  +97us] +/-  201us
^- 203.0.113.40                   3   6    17   421    -12ms[  -14ms] +/-   88ms

The Reach column is a rotating 8-bit register: 377 means the last eight polls all got a response. A value that decays to 0 means every poll is failing - firewall on UDP 123, a broken DNS answer, or an upstream that has stopped answering. ? in the state column is unreachable, x means the source disagrees with the majority, and a source stuck at stratum 16 is itself unsynchronised. Use chronyc -n sourcestats to see frequency and offset statistics per source, which is how you spot one server consistently pulling your clock the wrong way.

Common faults and fixes

• Clock off by hours after boot: the host could not reach a server before the step window closed. Check connectivity first, then correct immediately with chronyc makestep, and confirm makestep is present in the configuration.
• Virtual machines whose clock jumps: suspend/resume and host-side scheduling distort the guest clock. Prefer host time synchronisation (or the hypervisor's clock source), keep maxslewrate realistic and let chrony slew rather than fight the hypervisor with repeated steps.
• Slew taking forever: a large offset with stepping disabled is corrected at the slew rate limit. That is intentional - limit it with maxchange rather than disabling the guardrails entirely.
• Nothing synchronises, all sources ?: verify DNS resolution of the configured names, then test NTP reachability (chronyd -q -t 1 'server pool.ntp.org iburst maxsamples 1' runs a one-shot query without touching the running daemon).
• Kerberos/auth failures after a fix: services that cached time-dependent state need a restart - a step forward can invalidate tickets and tokens.

Hardening notes

Set minsources so a single compromised source cannot win, prefer authenticated NTS sources where the upstream supports it, and monitor Leap status and skew rather than only the offset - a host that is accurate today but with pathological skew will drift tomorrow.

Related: systemd-resolved and resolvectl troubleshooting, ss, netstat and tcpdump network troubleshooting, and Linux server operations guide.

原文链接：https://chrony-project.org/faq.html