Chrony NTP Server Configuration on Linux

Time is the substrate that every log, certificate and replication protocol depends on, and chrony is the default way to deliver it on Linux. This guide covers both roles - client syncing from upstream sources and server distributing time to a network - with the directives that matter in production: multiple sources, driftfile, makestep for fast initial correction, RTC sync, and access control via allow. It finishes with chronyc verification commands and the failure patterns that indicate a source is unreachable rather than simply inaccurate.

Client configuration

# /etc/chrony.conf
server ntp1.example.net iburst
server ntp2.example.net iburst
server ntp3.example.net iburst

driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
logdir /var/log/chrony

• iburst sends a burst of packets at startup so the first correction happens in seconds instead of minutes.
• driftfile records the local clock's rate error between reboots, which is the difference between settling quickly and re-learning the same offset every boot.
• makestep 1.0 3 allows chrony to step the clock rather than slew it for the first three updates, which matters on VMs and devices with a dead RTC. After the threshold, corrections are slewed - a step would break monotonic time for applications.
• rtcsync copies system time to the hardware clock periodically so the next boot starts close to correct.

Server configuration

# allow the management and server subnets
allow 10.10.10.0/24
allow 10.20.0.0/16
local stratum 8
clientloglimit 100000000
leapsectz right/UTC

allow is the access control list; without it the server answers nothing. local stratum 8 is used on an isolated network whose clock should be authoritative to its own clients but obviously not claim to be a real stratum-1 source. If your server is a VM with no reliable clock of its own, do not hand out unsynchronised time as though it were accurate - either sync it upstream or treat the whole segment as isolated.

Apply and verify

systemctl restart chronyd
chronyc tracking      # offset, frequency, stratum, leap status
chronyc sources -v    # upstream state; ^* means selected
chronyc sourcestats -v
chronyc clients       # on a server: who is asking
timedatectl status

In sources -v, a leading ^* marks the chosen source, ^+ a usable alternative, and ^- a source excluded by the selection algorithm. A source stuck at ^? is unreachable. In tracking, watch the System time offset trending toward microseconds and the Frequency value stabilising - a wildly swinging frequency usually means an unstable upstream, not a broken local clock.

Common failures

• Time drifts after reboot only. The RTC is stale or wrong; rtcsync plus hwclock --systohc at shutdown resolves it. Chassis with a dead CMOS battery are a real cause - see ipmitool BMC sensor and SEL operations for reading that condition from the BMC.
• Clients never sync. The server has no allow line, or a host firewall blocks UDP 123. Verify with chronyc clients on the server and chronyc sources on the client.
• Notification storms after a step. Some monitoring systems treat a time step as a data anomaly. Use makestep thresholds deliberately, and prefer slaving to a stable source over wide-open stepping.

Related: auditd and ausearch, where accurate timestamps decide whether two events can be correlated at all.

原文链接：https://chrony-project.org/doc/4.3/chrony.conf.html