3 of 3

Scheduling and TimeLesson 3 of 3

Time zones and time service clients with chrony

Set the time zone, point the system at an NTP server with chrony, and check that it is really synchronised.

  • timedatectl
  • chronyc
  • chronyc sources
  • chronyc tracking
  • /etc/chrony.conf
  • systemctl restart chronyd

40 min5 exercises

After this lesson you can

  • Read and change the time zone and the NTP setting with timedatectl.
  • Configure chronyd as a client of a given server and make the setting persistent.
  • Verify synchronisation with chronyc sources and tracking, and recognise the common failure causes.

The idea

Correct time matters for logs, certificates, Kerberos, cron, and anything that compares timestamps between machines. On RHEL the time service is chrony: chronyd is the daemon that talks to NTP servers, and chronyc is its control program. A system that only asks servers for the time (and never serves it to others) is a time client, which is all the exam asks for.

Two tools, two jobs:

ToolJob
timedatectlTime zone, whether NTP is on, human-readable status
chronycWhich servers chrony uses, how good the sync is

The configuration is /etc/chrony.conf. The default uses a pool of public servers:

pool 2.rhel.pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3

iburst sends several quick requests at start, so the first sync is fast. makestep 1.0 3 lets chrony jump the clock if it is off by more than 1 second during the first 3 updates, instead of slewing it slowly.

Try it

timedatectl
               Local time: Tue 2026-11-03 12:10:44 +03
           Universal time: Tue 2026-11-03 09:10:44 UTC
                 RTC time: Tue 2026-11-03 09:10:44
                Time zone: Asia/Riyadh (+03, +0300)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no
timedatectl list-timezones | grep -i riyadh
sudo timedatectl set-timezone Asia/Riyadh
Asia/Riyadh

Point the client at a server

Edit the file so only your server is used. Use server for one named host (and pool for a name that resolves to several):

sudo sed -i 's/^pool /#pool /' /etc/chrony.conf
echo 'server ntp.lab.example iburst' | sudo tee -a /etc/chrony.conf
sudo systemctl enable --now chronyd
sudo systemctl restart chronyd
chronyc sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* ntp.lab.example               2   6   377    35   +123us[ +187us] +/-   18ms

How to read it: the first column is ^ for a server (as opposed to a local reference clock), the second is the state: * is the source chrony is synchronised to, + a good candidate, ? unreachable, x an outlier. Reach is an octal history of the last 8 polls: 377 means all eight succeeded, 0 means none did.

chronyc tracking
Reference ID    : C0A80164 (ntp.lab.example)
Stratum         : 3
System time     : 0.000012345 seconds fast of NTP time
Last offset     : +0.000008765 seconds
Leap status     : Normal

When it does not synchronise

Work from the service outward. Is chronyd active (systemctl status chronyd)? Does chronyc sources list any source, and what is its Reach? Reach 0 after a minute means the packets are not getting through: wrong name, no route, or a firewall dropping UDP port 123. journalctl -u chronyd shows name-resolution failures. timedatectl set-time is refused while NTP is active; that is by design, so use chronyc makestep to correct a large offset.

Going further

chronyc -a makestep forces a step now. chronyc sourcestats gives long-term accuracy, chronyc clients (on a server) lists who is asking, and allow 192.168.0.0/24 in the config turns a host into a time server for that network. hwclock reads the hardware clock, which should stay in UTC (RTC in local TZ: no). If a virtual machine’s host injects time, chrony and the hypervisor’s sync can fight each other.

Practice

0 of 5 done

Do these on your own system. They get harder. Check each result, then tick it off.

  1. Warm-up

    Read the clock status

    Show the local time, UTC, time zone and whether the system clock is synchronised. Name the two fields that tell you NTP is working.

    Check your result

    timedatectl shows System clock synchronized: yes and NTP service: active.

    Hint

    timedatectl status.

    Solution
    timedatectl
  2. Practice

    Change the time zone

    Set the time zone to Asia/Riyadh and prove it with the date command, then set it back to what it was.

    Check your result

    date shows the +03 zone abbreviation, and timedatectl lists Time zone: Asia/Riyadh (+03, +0300).

    Hint

    timedatectl list-timezones | grep Riyadh finds the exact name. timedatectl set-timezone NAME.

    Solution
    timedatectl list-timezones | grep Riyadh
sudo timedatectl set-timezone Asia/Riyadh
date
timedatectl | grep 'Time zone'
  3. Practice

    Make this system a client of a given server

    Configure the system to synchronise with the NTP server ntp.lab.example (use any reachable server in your lab, or time.cloudflare.com) and nothing else. The change must survive a reboot. Show the configured source.

    Check your result

    /etc/chrony.conf has a server ... iburst line for your chosen server and no pool line. chronyc sources lists it, and a * marks it as selected once the clock is synchronised.

    Hint

    Edit /etc/chrony.conf: comment out the default pool line, add server NAME iburst, then sudo systemctl restart chronyd and sudo systemctl enable chronyd.

    Solution
    sudo sed -i 's/^pool /#pool /' /etc/chrony.conf
echo 'server time.cloudflare.com iburst' | sudo tee -a /etc/chrony.conf
sudo systemctl enable --now chronyd
sudo systemctl restart chronyd
chronyc sources
  4. Practice

    How far off are we, and fix it now

    Show the current offset from the time source, and force an immediate correction instead of waiting for a gradual adjustment.

    Check your result

    chronyc tracking prints System time : 0.000... seconds fast/slow of NTP time. sudo chronyc makestep prints 200 OK.

    Hint

    chronyc tracking and chronyc makestep.

    Solution
    chronyc tracking
sudo chronyc makestep
  5. Challenge

    It will not synchronise: find out why

    The clock shows System clock synchronized: no. Work through the checks in order and state the likely cause for each: is chronyd running, does chronyc sources show any source and its Reach value, can the system reach the server on UDP port 123, and is the system hosting its own time service already? Fix a deliberately wrong server name you add to chrony.conf.

    Check your result

    With a typo in the server name chronyc sources shows no usable source (or Reach 0). After correcting the name and restarting chronyd, Reach climbs toward 377 and a ^* source appears.

    Hint

    systemctl status chronyd, chronyc sources -v, journalctl -u chronyd. A firewall in between blocks UDP 123.

    Solution
    systemctl status chronyd --no-pager
chronyc sources -v
sudo journalctl -u chronyd --no-pager | tail
echo 'server nosuchhost.invalid iburst' | sudo tee -a /etc/chrony.conf
sudo systemctl restart chronyd
chronyc sources
sudo sed -i '/nosuchhost/d' /etc/chrony.conf
sudo systemctl restart chronyd