When a Linux host drifts after reboot, a VM pause, or manual clock changes, you usually want a Chrony force sync right away—not a slow slew over many minutes. This guide puts force sync first (chronyc makestep and chronyd -q), then shows how to check Chrony sync status, configure Chrony as an NTP client or server on RHEL, CentOS, and Ubuntu, and read common chrony.conf options such as iburst, minpoll, and maxpoll.
Tested on: chrony 4.6.1 (
chronyd -v); Ubuntu 25.04; kernel 6.14.0-37-generic.
The same commands work on RHEL 8/9, CentOS Stream, AlmaLinux, and Rocky Linux; paths and service names differ slightly and are called out below.
Force Chrony time sync
By default, chronyd slews the clock for small corrections. To jump the clock immediately, use one of these patterns.
Force sync while chronyd is running (chronyc makestep)
When chronyd is already running and has reachable sources, step the clock now:
sudo chronyc makestepIf chronyd accepted the request, you should see a short confirmation like:
200 OKThat means chronyd will step the clock instead of waiting for the normal slew. Use this after large drift or when chronyc tracking still shows an offset you want cleared quickly. Be aware that a sudden step can confuse time-sensitive applications, so prefer a maintenance window on production nodes.
If chronyc reports 506 Cannot talk to daemon, start the service first (sudo systemctl start chronyd on RHEL, sudo systemctl start chrony on Ubuntu).
One-shot force sync (chronyd -q)
To sync once and exit—useful in scripts or when the daemon is stopped—run chronyd in query mode. It reads servers from your config file unless you pass an inline configuration string:
sudo systemctl stop chronyd # RHEL/CentOS: chronyd
# Ubuntu: sudo systemctl stop chrony
sudo chronyd -qOr point at a pool or server directly:
sudo chronyd -q 'pool pool.ntp.org iburst maxsources 4'
sudo chronyd -q 'server 192.168.1.10 iburst'When sync succeeds, chronyd prints a line showing how far the clock was off, applies the correction, and exits. Your timestamps and offset will differ, but the log looks similar to:
2026-06-23T09:31:07Z chronyd version 4.6.1 starting (+CMDMON +NTP ...)
2026-06-23T09:31:13Z System clock wrong by 0.004855 seconds (step)
2026-06-23T09:31:13Z chronyd exitingAs you can see, a successful one-shot run ends with chronyd exiting after the (step) or (slew) line. Start the service again when you are done:
sudo systemctl start chronyd # RHEL/CentOS
# Ubuntu: sudo systemctl start chronyAllow an initial step in chrony.conf (makestep)
Most distro packages ship a makestep line so the first few updates after boot can step large offsets. On Ubuntu and RHEL you will often find:
makestep 1 3That means: if the correction is larger than one second, step the clock—but only for the first three updates. After that, chronyd slews unless you run chronyc makestep or use chronyd -q.
Check Chrony sync status
Start with timedatectl—it is the quickest yes/no for NTP on systemd systems:
timedatectl statusRight after you enable NTP, before the first successful poll, you may still see:
Local time: Tue 2026-06-23 14:57:41 IST
Universal time: Tue 2026-06-23 09:27:41 UTC
System clock synchronized: no
NTP service: activeOnce Chrony has locked to a source, System clock synchronized should change to yes while NTP service stays active. If NTP is inactive, turn it on with:
sudo timedatectl set-ntp yesFor more detail, run chronyc tracking. It shows which source you are using and whether the clock is considered in sync:
chronyc trackingWhen you are synchronized, look for Leap status: Normal and a real hostname or IP in Reference ID. If upstream servers are still unreachable, the leap line may read:
Leap status : Not synchronisedTo see which server Chrony selected, run chronyc sources -v. The current sync source is marked with ^*:
chronyc sources -vWhen your network can reach NTP servers, a healthy client looks similar to this (names and offsets vary by site):
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* time.cloudflare.com 3 6 377 12 -245us[ -312us] +/- 22ms
^+ 162.159.200.1 3 6 377 10 +1200us[+1200us] +/- 45msThe ^* row is the server your clock is following. A full Reach value (often 377 in octal) means recent polls succeeded.
To count how many sources are usable, run:
chronyc activityYou should see how many sources are online, for example:
200 OK
4 sources online
0 sources offlineOn RHEL/CentOS, check the unit with systemctl status chronyd; on Ubuntu use systemctl status chrony.
Configure Chrony as NTP client
Install Chrony if it is not already on the system:
# RHEL / CentOS / Rocky / Alma
sudo dnf install -y chrony
sudo systemctl enable --now chronyd
# Ubuntu / Debian
sudo apt install -y chrony
sudo systemctl enable --now chronyFor RHEL and CentOS, edit /etc/chrony.conf and add a minimal client layout like this:
pool pool.ntp.org iburst maxsources 4
driftfile /var/lib/chrony/drift
makestep 1 3
rtcsyncOn Ubuntu and Debian, upstream pools may already live in /etc/chrony/sources.d/ (for example ubuntu-ntp-pools.sources). You can add a .sources file there or put pool lines in /etc/chrony/chrony.conf. The drift file path is often /var/lib/chrony/chrony.drift.
After you save the file, restart the service:
sudo systemctl restart chronyd # RHEL/CentOS
# Ubuntu: sudo systemctl restart chronyThen confirm with timedatectl and chronyc sources -v. Your host needs outbound UDP port 123 to the NTP servers and working DNS or routing when you use pool hostnames.
To use one internal server instead of a public pool, replace the pool line with:
server 192.168.1.10 iburst
driftfile /var/lib/chrony/drift
makestep 1 3
rtcsyncConfigure Chrony as NTP server
If a host already syncs to the internet, you can serve time to other machines on your LAN. On that server, add allow for the client subnet in chrony.conf (RHEL) or in chrony.conf / a file under /etc/chrony/conf.d/ (Ubuntu):
allow 192.168.0.0/24Without allow, chronyd runs as a client only and does not answer NTP requests from the network.
If the server has no internet upstream but must still answer clients, some admins add local stratum 10—only when you accept serving time from an unsynchronised local clock.
Restart the service and allow UDP 123 through the host firewall.
On each client, point chrony.conf at the server IP:
server 192.168.0.113 iburst
driftfile /var/lib/chrony/drift
makestep 1 3
rtcsyncAfter you restart the client, run chronyc sources and look for ^* beside the server IP. chronyc tracking should list that same address as Reference ID.
Chrony server options explained
These options go on server or pool lines in chrony.conf (or Ubuntu .sources files):
| Option | Purpose |
|---|---|
pool name iburst |
Resolve a pool hostname to several NTP servers; iburst sends up to four quick requests at startup so sync happens within seconds instead of waiting for the first long poll interval. |
server ip-or-name iburst |
Use one NTP server; common for internal LAN servers. |
minpoll N |
Minimum interval between requests as (2^N) seconds. If you omit it, the default is minpoll 6 (64 seconds) on RHEL 8, CentOS, and Ubuntu 22.04/24.04 with chrony 4.x. |
maxpoll N |
Maximum interval (2^N) seconds. Default is 10 (1024 seconds). |
makestep threshold limit |
Step if offset exceeds threshold seconds, but only for the first limit clock updates (package defaults are often makestep 1 3). |
rtcsync |
Copy the system clock to the hardware RTC periodically so the clock survives reboots; keep this on unless you have a reason to disable it. |
allow subnet |
Let NTP clients on that subnet query this host as a server. |
driftfile path |
Store estimated clock drift between restarts. |
You can combine poll tuning with a public pool like this:
pool pool.ntp.org iburst minpoll 6 maxpoll 10 maxsources 4With iburst, the first packets still go out within about two seconds even when minpoll is 6—that is why boot-time sync feels fast while steady-state polling stays at 64 seconds or longer.
Common Chrony sync issues
System clock synchronized: no but NTP service is active
Wait 30–60 seconds after systemctl restart chronyd—iburst needs a few round trips. Run chronyc sources -v and check the Reach column (octal 377 means recent successful polls). If every source shows ? or Reach 0, your host cannot reach UDP 123 (firewall, routing, or blocked outbound NTP).
506 Cannot talk to daemon
chronyd is not running. Start it with sudo systemctl start chronyd (RHEL) or sudo systemctl start chrony (Ubuntu).
chronyd -q exits with “No suitable source for synchronisation”
No NTP server responded—check DNS, outbound UDP 123, and the pool or server name in your -q argument or config file.
Wrong config file edited on Ubuntu
Ubuntu splits pools into /etc/chrony/sources.d/*.sources. Editing only /etc/chrony/chrony.conf without checking sources.d is a common mistake. Run grep -r pool /etc/chrony/ to see which upstreams are active.
chronyc makestep returns OK but offset remains large
You may have no selected source (^* missing in chronyc sources). Fix upstream connectivity first; stepping without a reference does not set correct time.
Large step broke an application
Plan emergency steps in a maintenance window when you can. For recurring drift, fix VM or hypervisor time sync and keep rtcsync enabled.
Summary
To force Chrony time sync on RHEL, CentOS, or Ubuntu, use chronyc makestep while chronyd is running, or chronyd -q for a one-shot sync from chrony.conf or an inline pool/server line. Check status with timedatectl, chronyc tracking, and chronyc sources -v. Configure a client with pool or server, driftfile, makestep, and rtcsync; configure a server with allow for your subnet. Default minpoll is 6 (64 seconds) when unset; iburst still speeds up the first sync after boot. For timezone changes separate from NTP, see Ubuntu timezone setup.
