Clock time and timezone are different
The displayed clock looks reasonable, yet TLS or Kerberos authentication fails. Separate actual system time from its presentation: the timezone changes display, while Chrony synchronizes the clock through NTP. This tutorial examines time sources, offset and synchronization status; switching Asia/Tehran to UTC alone does not correct clock skew.
Time daemon and NTP reachability
The example uses Ubuntu 24.04 LTS and Chrony. Record the installed version and active time daemon.
No special compute capacity is needed. In VMs, inspect hypervisor synchronization so competing mechanisms do not repeatedly change the clock.
Prepare sudo and UDP/123 access to real sources, replacing sample addresses. NTS also requires supported sources and its separate TLS path.
Chrony and timesyncd
timesyncd is another option for simple clients. Chrony owns synchronization here. Timedatectl timesync-status reports timesyncd. Use sources and tracking for Chrony.
Sources, kernel clock and applications
Chronyd measures responses from time sources and corrects the kernel clock's error. Applications use that clock; the timezone only determines its presentation. A sudden clock step can therefore affect scheduling and databases and needs different handling from a display-only timezone change.
Example: two internal sources
Servers use 10.20.30.53 and 10.20.30.54, with central logs in UTC. Sources need independent dependencies. Two disagreeing sources do not establish which is correct. Design additional source diversity for fault tolerance.
Restrict NTP and review clock steps
Restrict sources to approved destinations and avoid unintentionally exposing a public NTP server. Inspect existing makestep before restart. Restart resets the update count, so startup policy might step time without a manual makestep command.
Configure sources and verify synchronization
Record the active daemon and existing sources before installing anything so the change is traceable. One daemon should own synchronization afterwards. Installing chrony usually replaces timesyncd, but verify that result on this system rather than inferring it from package-install success.
timedatectl status
date -u --iso-8601=seconds
sudo apt-get update
sudo apt-get install -y chrony
systemctl is-active chrony systemd-timesyncd
sudo cp -a /etc/chrony /root/chrony-before-changeReview existing pool/server lines and generated sourcedir entries in /etc/chrony/chrony.conf. Remove conflicting sources only after identifying their ownership. These complete source lines replace public sources with approved internal ones.
server 10.20.30.53 iburst
server 10.20.30.54 iburstRun the following commands one at a time. After printing the configuration with chronyd -p and before restarting, inspect makestep and DHCP-supplied sources. If abrupt clock correction is unacceptable, align policy with the workload and use an appropriate maintenance window.
sudo chronyd -p -f /etc/chrony/chrony.conf
sudo systemctl restart chrony
chronyc sources -v
chronyc tracking
sudo timedatectl set-timezone Asia/Tehran
date -u --iso-8601=secondsAfter several polling intervals, expect a source marked ^*, Reach moving towards 377, and Leap status: Normal. The displayed source name may come from reverse DNS. For a large offset on a production system, evaluate database and scheduling effects before using makestep.
Offsets and the selected source
Monitor offset, stratum, reach and source changes. A 100 ms offset for five minutes is an example threshold to align with application needs. Active Chrony does not establish synchronization.
Interpret Chrony evidence without stepping the clock
Illustrative fields, not measured output: a source row with ^*, Reach 377 and a small Last sample has been selected and has eight recent successful replies; 377 is an octal reach register, not a percentage. In tracking, Leap status Normal, Reference ID and System time quantify sync state and offset. Stratum alone is not accuracy. A source marked ^? with Reach 0 needs source/network investigation; ^x is treated as a falseticker. Allow multiple polling cycles before judging a newly started service.
Zero reach or clock jumps
^? marks a currently unusable source. Check UDP, DNS and its clock. ^x marks a source identified as a falseticker.
chronyc sources -v
chronyc sourcestats -v
chronyc tracking
sudo journalctl -u chrony -n 80 --no-pagerReach zero means there are no successful valid replies in the current eight-poll reachability window; the service may have synchronized earlier and then lost contact. This is not merely a clock-display issue. For repeated VM clock jumps, compare hypervisor synchronization, the guest daemon and step policy. For certificate expiry, compare actual time with notAfter; changing the timezone will not fix that failure.
Restore sources before sensitive workloads
Version configuration, source inventory and timezone. Restore prior settings after reviewing step policy and inspect tracking. Confirm synchronization after long downtime before starting sensitive workloads.
UTC records and local display
Use UTC for logs and suitable local display for users. Assess workload effects of manual clock or source changes. Avoid unplanned production steps for large offsets.
Best Practices
- Version-control configuration and review changes.
- Use least privilege and explicit allow-lists.
- Automate repeatable checks and monitor the expected state.
- Test upgrades and restores before production rollout.
Conclusion
A reliable implementation of Configure Ubuntu Time Synchronization with Chrony is more than a successful first run. Keep the configuration documented, observable, recoverable, and aligned with the team's change-management process.
Frequently Asked Questions
Does a wrong timezone cause TLS failure?
TLS relies on the actual clock. Timezone settings change only its display.
Does an active chrony service mean it is synchronized?
No. Check selected sources, offset and Leap status.
