Use NTP/Chronyd to Sync Time

You can easily keep your system's date and time accurate by using the Network Time Protocol (NTP). An accurate clock ensures that timestamps in emails, logs, and authentication tickets are correct, and it's especially helpful when you need to correlate log entries across multiple servers. If you don't correct the system clock periodically, it will slowly drift away from an accurate setting — that's what NTP is for.

Which daemon handles this depends on your OS release. Older releases use ntpd; current releases use chronyd instead, and on RHEL 8 and later ntpd isn't available at all.

If you're not sure which daemon a given host is running, check:

systemctl status chronyd
systemctl status ntpd
systemctl status systemd-timesyncd

---

Part 1 — Legacy OS: ntpd

Applies to RHEL/CentOS 6–7 and Ubuntu releases before 18.04 LTS.

Install

RHEL/CentOS:

yum install ntp

Ubuntu/Debian:

apt-get install ntp

One-time sync vs. continuous sync

You can set your clock to sync at times you specify by using cron to run ntpdate, or you can run the NTP daemon continuously. Running the daemon is the better option — it uses less bandwidth and keeps time more accurately by tracking your clock's drift over time and adjusting for it, rather than applying a single correction.

For a one-time sync:

ntpdate pool.ntp.org

Configure /etc/ntp.conf

Add one or more server lines:

server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst

Use more than one server entry. With three or more servers, ntpd queries all of them and selects a time that most of the polled servers agree on, which is more accurate than syncing against a single source.

iburst speeds up the initial sync slightly — it helps but isn't essential. The dynamic option, appended after a server line, tells ntpd it can retry that server later if it's unavailable right now; this matters mainly on machines that don't always have a connection to the internet, and isn't necessary on a host with a dedicated one.

Protect the server against NTP-based attacks by adding:

disable monitor

This turns off the remote-query feature (monlist) that older NTP implementations expose, which has been abused for reflection/amplification DDoS attacks.

If you have more than one machine to sync, designate one as the master NTP server and have the others sync against it, rather than pointing every host at external servers independently.

Start and enable the service

RHEL/CentOS 7 (systemd):

systemctl start ntpd
systemctl enable ntpd

RHEL/CentOS 6 (SysV init):

service ntpd start
chkconfig ntpd on

Ubuntu, pre-18.04:

service ntp start

Verify

ntpq -p

This lists the configured peers, their stratum, and offset. A * next to a peer marks the one currently selected as the sync source. If NTP runs into problems, it logs them to the system log — /var/log/messages on RHEL/CentOS, /var/log/syslog on Debian/Ubuntu — which is worth checking if sync stalls.

---

Part 2 — Current OS: chrony

Applies to RHEL/CentOS/Rocky/AlmaLinux 8–9 and Ubuntu 18.04–24.04 LTS.

Install

RHEL/CentOS/Rocky/AlmaLinux:

dnf install chrony

Ubuntu/Debian:

apt install chrony

RHEL 9 and later implement NTP only through the chronyd daemon, provided by the chrony package.

Configure /etc/chrony.conf

Two directives define your time sources: server for a single NTP server, and pool for a pool of servers resolved via DNS.

pool 2.rhel.pool.ntp.org iburst

or for a specific server:

server ntp.example.com iburst

A minimal client configuration also sets:

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

driftfile records the rate at which the system clock gains or loses time, so chronyd compensates faster after a restart. makestep lets chronyd step (jump) the clock instead of slewing it, but only during the first three updates — that clears a large initial offset quickly without letting the clock jump arbitrarily afterward. rtcsync keeps the hardware clock synced from the kernel.

On RHEL/CentOS 7, chrony is preferred over ntpd for all systems except ones managed by tools that don't support chrony, or ones with a hardware reference clock chrony can't use.

Note that the restrict directive from legacy ntp.conf files isn't part of chrony's syntax — access control in chrony.conf uses allow/deny instead.

Start and enable the service

systemctl start chronyd
systemctl enable chronyd

Verify

Check overall sync status:

timedatectl status

You should see:

System clock synchronized: yes
NTP service: active

Check current sources and which one chrony has selected:

chronyc sources

Check detailed tracking stats — reference ID, stratum, offset, root delay/dispersion:

chronyc -N tracking

Ubuntu 18.04–24.04 LTS: systemd-timesyncd vs. chrony

On these releases, systemd-timesyncd — a lightweight SNTP client — is the default, not chrony. If chrony is installed, timesyncd automatically steps back so the two don't conflict, and chrony takes over timekeeping.

Stick with timesyncd for basic client-only sync. Move to chrony if you need to serve NTP to other hosts, need Network Time Security (NTS), or want the tighter drift-tracking behavior described above. Timesyncd's server list lives in /etc/systemd/timesyncd.conf, using space-separated NTP= and FallbackNTP= entries.

If you're staying on timesyncd only:

timedatectl set-ntp true
systemctl status systemd-timesyncd

---

Firewall

NTP uses UDP port 123. If a host firewall — firewalld, ufw, iptables — blocks UDP 123 inbound or outbound, sync will fail even with a correct daemon configuration. Confirm the port is open before troubleshooting anything else.

---

For background on NTP itself and available public server pools, see the NTP documentation site at ntp.org. For chrony-specific configuration reference beyond what's covered here, see your distribution's chrony documentation (Red Hat's "Configuring time synchronization" chapter for RHEL, or the Ubuntu Server Guide's chrony pages for Ubuntu).