Loading...

VONDS ©

Lab 77: Time Synchronization with chrony

Back to Lab Index

Stabilize a host with incorrect time by installing and operating chrony tooling on a RHEL system. Validate upstream sources, apply an immediate correction when appropriate, and ensure chronyd is enabled and healthy across reboots.

time services core

Scenario

A server’s system time is incorrect and is causing operational issues such as failed TLS handshakes, log timestamps that do not align across hosts, and unreliable scheduling behavior. You need to synchronize time using chrony and confirm the service stays healthy across reboots.

Operator context

Correct time is a dependency for authentication, logging, monitoring correlation, and certificate validation. Treat time sync as a baseline system health requirement before deeper service-level troubleshooting.

Objective

  • Install chrony using the system package manager.
  • Inspect configured time sources and synchronization state.
  • Force an immediate step correction when appropriate.
  • Enable and start chronyd so it persists across reboots.
  • Confirm tracking signals indicate stable synchronization.

Concepts

  • Time sync as a platform dependency: TLS validation, authentication, logs, and scheduled workloads.
  • chrony components: chronyd (daemon) and chronyc (control client).
  • Source selection and reachability: interpreting chronyc sources -v markers like ^*.
  • Slew versus step: gradual correction during steady state versus a one-time correction after large drift.
  • Service persistence: enabling chronyd and verifying health after boot.

Walkthrough

Step 1 : Install chrony.
Command 
sudo dnf install -y chrony

Installing chrony provides the chronyd daemon and the chronyc control utility. On RHEL, chrony is the standard NTP implementation. 

Dependencies resolved.
Install  1 Package
Installing       : chrony-4.4-1.el9.x86_64
Step 2 : Enable and start chronyd.
Command 
sudo systemctl enable --now chronyd

This ensures the daemon starts immediately and persists across reboots. Starting the service also triggers an initial sync attempt once sources are reachable. 

Created symlink /etc/systemd/system/multi-user.target.wants/chronyd.service → /usr/lib/systemd/system/chronyd.service.
Job for chronyd.service started successfully.
Step 3 : Query current time sources.
Command 
chronyc sources -v

This shows configured sources and whether the host is synchronized. Look for ^* as the selected source and confirm the reach register is non-zero. 

MS Name/IP address         Stratum Poll Reach LastRx Last sample
^* time.cloudflare.com          3   6   377    32   -0.000123   0.000345
^+ 0.rhel.pool.ntp.org          2   6   377    58   -0.000456   0.000789
Step 4 : Force an immediate correction when the clock is significantly wrong.
Safety note

Stepping time can disrupt time-sensitive workloads. Use makestep when the clock is substantially wrong (for example after a VM restore), and prefer normal steady-state synchronization for routine drift.

Command 
sudo chronyc makestep

This requests an immediate correction rather than waiting for small gradual adjustments to converge. Use it sparingly and only when you understand the blast radius. 

200 OK
makestep: adjusted offset by 0.000456 seconds
Step 5 : Confirm sync status and tracking signals.
Commands 
chronyc tracking
chronyc sources -v

tracking summarizes sync behavior and offsets. Re-checking sources confirms reachability and which upstream is selected. 

# Example signals that time sync is healthy:
# Leap status     : Normal
# System time     : ... seconds fast/slow of NTP time
# ^* indicates current selected source

Common breakpoints

chronyd is running but sources show Reach 0

The service is up, but upstream servers are not reachable. Confirm outbound UDP/123 is allowed, check DNS resolution for pool hostnames, and validate that the system has network connectivity.

No selected source marker (^*) appears

chrony may not have enough samples yet or may be rejecting sources. Wait for additional polling, then re-run chronyc sources -v and inspect chronyc tracking for leap or reference status signals.

Large time jump causes service disruption

If stepping time impacts workloads, stabilize the host during a maintenance window. For systems with strict time requirements, coordinate the correction with application owners and monitoring teams.

systemctl enable --now fails

Confirm the unit name is correct (chronyd on RHEL) and the package is installed. If the unit fails to start, review service logs with journalctl -u chronyd.

Cleanup checklist

This lab does not create temporary files. Your cleanup is confirming chrony remains enabled and tracking remains stable after reboots.

Commands 
systemctl is-enabled chronyd
systemctl status chronyd --no-pager
chronyc tracking
chronyc sources -v
Success signal

chronyd is enabled, the service is active, and chronyc sources -v shows a selected upstream (^*) with non-zero reach.

Reference

  • dnf install -y chrony : Installs chrony tooling on RHEL systems.
    • -y : Automatically answers “yes” to prompts.
  • systemctl enable --now chronyd : Enables chrony at boot and starts it immediately.
    • enable : Configures the service to start on boot.
    • --now : Starts the service immediately.
  • chronyc sources -v : Lists configured time sources and their status.
    • ^* : Indicates the currently selected source.
    • Reach : Octal reachability register showing recent successful polls.
  • chronyc makestep : Forces an immediate step correction of system time.
  • chronyc tracking : Displays synchronization status and time offset metrics.
  • journalctl -u chronyd : Shows service logs for chrony.
    • -u chronyd : Filters logs to the chronyd unit.