Time sync with chrony: clocks, time zones and NTP

Steps 1 to 7 only read information, apart from setting the time zone. Step 8 changes chrony on both VMs and opens a firewall port on rocky01. The times, IP addresses and offsets in your output will differ, because the pool hands out different servers to everyone.

1Read the clock with timedatectl

Run this on rocky01, then on ubu01:

timedatectl

You should see something like this on rocky01:

               Local time: Tue 2026-10-27 11:31:07 IST
           Universal time: Tue 2026-10-27 06:01:07 UTC
                 RTC time: Tue 2026-10-27 06:01:07
                Time zone: Asia/Kolkata (IST, +0530)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Local time and Universal time are the same moment shown in two ways, five and a half hours apart. RTC time is the hardware clock, kept in UTC (“RTC in local TZ: no”, which is what you want on Linux). “System clock synchronized: yes” means chrony has a good source and has brought the clock into line; “NTP service: active” means the time service is running.

ubu01 shows the same layout. If its Time zone line says Etc/UTC (UTC, +0000), the Ubuntu installer didn’t pick a zone for you, which is normal on cloud images; step 6 sets it.

✅ Checkpoint: Both VMs say “System clock synchronized: yes” and “NTP service: active”.

2Find the service that keeps time

Run this on rocky01:

systemctl is-active chronyd
ps -o user,pid,cmd -C chronyd

You should see something like this:

active
USER         PID CMD
chrony       760 /usr/sbin/chronyd -F 2

And on ubu01, where the unit is called chrony:

systemctl is-active chrony
ps -o user,pid,cmd -C chronyd

You should see something like this:

active
USER         PID CMD
_chrony      812 /usr/sbin/chronyd -n -F 1

The program is chronyd on both, running as its own unprivileged user, and -F turns on a seccomp filter that limits which system calls it may make. On Ubuntu systemctl is-active chronyd also works, because chronyd is an alias of chrony.service. You won’t find systemd-timesyncd on a fresh 26.04 server: the chrony package conflicts with it, so installing one removes the other.

✅ Checkpoint: chronyd is active on both VMs.

3Read chrony’s configuration

Run this on rocky01:

grep -Ev '^(#|$)' /etc/chrony.conf

You should see something like this (your file may have one or two more lines, such as keyfile):

pool 2.rocky.pool.ntp.org iburst
sourcedir /run/chrony-dhcp
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync
ntsdumpdir /var/lib/chrony
logdir /var/log/chrony

And on ubu01, where the servers live in their own file:

grep -Ev '^(#|$)' /etc/chrony/sources.d/ubuntu-ntp-pools.sources
grep -E '^(makestep|rtcsync|sourcedir|confdir)' /etc/chrony/chrony.conf

You should see this:

pool 1.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 2.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 3.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool 4.ntp.ubuntu.com iburst maxsources 1 nts prefer
pool ntp-bootstrap.ubuntu.com iburst maxsources 1 nts certset 1
sourcedir /run/chrony-dhcp
sourcedir /etc/chrony/sources.d
makestep 1 3
rtcsync
confdir /etc/chrony/conf.d

makestep 1.0 3 (written makestep 1 3 on Ubuntu) means “step the clock if it’s more than one second out, but only in the first three updates”. sourcedir /run/chrony-dhcp adds any NTP servers your DHCP server hands out. Ubuntu keeps its server list in sources.d, so you can add your own file there without touching the package’s config.

✅ Checkpoint: You found the pool line on rocky01 and the five NTS pool lines on ubu01.

4See which servers chrony uses

Run this on rocky01:

chronyc sources -v

You should see something like this:

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* 203.0.113.41                  2   7   377    52   -312us[ -405us] +/-   18ms
^+ 198.51.100.17                 2   7   377    49  +1204us[+1112us] +/-   35ms
^- 192.0.2.88                    3   7   377    51  +2981us[+2889us] +/-   61ms
^+ 203.0.113.150                 2   7   377   115   -876us[ -968us] +/-   27ms

The legend at the top explains the first two columns. ^* is the source chrony follows, ^+ sources agree and are combined with it, and ^- is usable but left out, probably because it’s further away (stratum 3). Reach is an octal record of the last eight polls: 377 means all eight answered. Last sample is how far your clock was from that server: a few hundred microseconds is excellent for a VM.

✅ Checkpoint: One line starts with ^* and Reach is 377 (or climbing towards it) for most sources.

5Check how far off the clock is

Run this on rocky01:

chronyc tracking

You should see something like this:

Reference ID    : CB007129 (203.0.113.41)
Stratum         : 3
Ref time (UTC)  : Tue Oct 27 06:02:31 2026
System time     : 0.000214532 seconds slow of NTP time
Last offset     : -0.000093117 seconds
RMS offset      : 0.000418274 seconds
Frequency       : 3.482 ppm fast
Residual freq   : -0.004 ppm
Skew            : 0.091 ppm
Root delay      : 0.031872012 seconds
Root dispersion : 0.001523644 seconds
Update interval : 129.3 seconds
Leap status     : Normal

Reference ID is the selected server (CB007129 is 203.0.113.41 in hex), and rocky01 itself is now stratum 3, one more than its source. System time is the line that matters most: the clock is 0.2 milliseconds slow of NTP time and chrony is slewing it. Frequency says this VM’s clock gains 3.5 parts per million, about 0.3 seconds a day, which chrony corrects all the time.

“Leap status: Not synchronised” would mean chrony has no usable source.

✅ Checkpoint: System time is well under one second and Leap status says Normal.

6Set the time zone and compare zones

Find zone names, then show one moment in four ways on rocky01:

timedatectl list-timezones | grep -E 'Kolkata|London|New_York'
date '+%F %T %Z'
TZ=Europe/London date '+%F %T %Z'
TZ=America/New_York date '+%F %T %Z'
date -u '+%F %T %Z'

You should see something like this:

America/New_York
Asia/Kolkata
Europe/London
2026-10-27 11:33:20 IST
2026-10-27 06:03:20 GMT
2026-10-27 02:03:20 EDT
2026-10-27 06:03:20 UTC

Same second, four labels. London has already left summer time on 25 October, so it shows GMT, while New York is still on EDT until 1 November. TZ=... changes the zone for one command only.

Now set ubu01’s zone for good (if it already says Asia/Kolkata, the command changes nothing):

sudo timedatectl set-timezone Asia/Kolkata
timedatectl | grep 'Time zone'
ls -l /etc/localtime

You should see something like this:

                Time zone: Asia/Kolkata (IST, +0530)
lrwxrwxrwx 1 root root 34 Oct 27 11:35 /etc/localtime -> ../usr/share/zoneinfo/Asia/Kolkata

✅ Checkpoint: ubu01 shows Asia/Kolkata (IST, +0530) and /etc/localtime points at it.

7Look at the hardware clock

Run this on rocky01:

sudo hwclock --show
timedatectl | grep -E 'RTC'

You should see something like this:

2026-10-27 11:36:02.512304+05:30
                 RTC time: Tue 2026-10-27 06:06:02
          RTC in local TZ: no

hwclock reads the chip and prints it in local time; timedatectl shows the raw value, which is UTC. In VirtualBox the “hardware clock” comes from the host, and the VM setting “Hardware Clock in UTC Time” (System, Motherboard) should stay ticked for Linux guests. Keep the RTC in UTC: storing local time in it causes a one-hour mess twice a year in any zone with summer time.

[Add your screenshot here]: VirtualBox, rocky01 Settings, System, Motherboard tab, with “Hardware Clock in UTC Time” ticked.

✅ Checkpoint: The hardware clock agrees with the system clock to within a second, and RTC in local TZ is no.

8Serve time to the lab from rocky01

On rocky01, allow the lab network, restart chronyd and open the firewall:

sudo cp -a /etc/chrony.conf /etc/chrony.conf.bak
echo 'allow 10.10.10.0/24' | sudo tee -a /etc/chrony.conf
sudo systemctl restart chronyd
sudo firewall-cmd --permanent --add-service=ntp
sudo firewall-cmd --reload
sudo firewall-cmd --list-services
sudo ss -ulnp | grep chronyd

You should see something like this:

allow 10.10.10.0/24
success
success
cockpit dhcpv6-client ntp ssh
UNCONN 0      0            0.0.0.0:123        0.0.0.0:*    users:(("chronyd",pid=1544,fd=7))
UNCONN 0      0          127.0.0.1:323        0.0.0.0:*    users:(("chronyd",pid=1544,fd=5))
UNCONN 0      0              [::1]:323           [::]:*    users:(("chronyd",pid=1544,fd=6))

chronyd only opens port 123 for other machines once an allow line exists; before this it listened on 323 for chronyc alone (you saw that in Lesson 23). The firewalld service ntp opens 123/udp, as in Lesson 34. Now point ubu01 at rocky01 with a file of its own in sources.d:

On ubu01:

echo 'server rocky01.saatlab.test iburst' | sudo tee /etc/chrony/sources.d/saatlab.sources
sudo chronyc reload sources
sleep 20
chronyc -N sources

You should see something like this:

server rocky01.saatlab.test iburst
200 OK
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* 1.ntp.ubuntu.com              2   6   377    34   -201us[ -287us] +/-   92ms
^+ 2.ntp.ubuntu.com              2   6   377    35   +412us[ +326us] +/-   97ms
^+ 3.ntp.ubuntu.com              2   6   377    33   -655us[ -741us] +/-   95ms
^+ 4.ntp.ubuntu.com              2   6   377    36   +128us[  +42us] +/-  101ms
^- ntp-bootstrap.ubuntu.com      2   6   377    35  +1820us[+1734us] +/-  118ms
^- rocky01.saatlab.test          3   6    17     4   +247us[ +247us] +/-   19ms

-N prints the names from the config files instead of reverse DNS names, which is clearer with pools. rocky01 is reachable (Reach 17 after four polls) at stratum 3, and ubu01 keeps following its NTS servers, which the Ubuntu file marks with prefer. At work you’d remove the public pools and list two or three internal servers instead. Back on rocky01, check that the requests arrive:

sudo chronyc clients

You should see something like this:

Hostname                      NTP   Drop Int IntL Last     Cmd   Drop Int  Last
===============================================================================
ubu01.saatlab.test             11      0   6   -    18       0      0   -     -

✅ Checkpoint: ubu01 lists rocky01.saatlab.test with Reach above 0, and rocky01 lists ubu01 as a client.

9Check sync the way a script would

Run this on either VM:

timedatectl show -p Timezone -p NTPSynchronized
chronyc tracking | awk '/^System time/ {print $4, $5, $6}'

You should see something like this:

Timezone=Asia/Kolkata
NTPSynchronized=yes
0.000214532 seconds slow

timedatectl show prints properties as Name=value, which a script can test without parsing a table, and awk pulls the offset out of tracking. A monitoring check usually alerts when NTPSynchronized is no for more than a few minutes, or when the offset passes a limit such as 100 ms; that would make a good tenth check for saat-health.sh from Lesson 39.

✅ Checkpoint: NTPSynchronized is yes and you can read the offset as one line.