NTP & Time

Most important commands to remember

• timedatectl status — inspect system time and timezone status.
• chronyc tracking — inspect the clock’s synchronization estimate.
• chronyc sources -v — inspect time sources and selection state.

Commands and flags

Command or option	Meaning
timedatectl status	Show local/UTC clock information and available synchronization status.
chronyc tracking	Report reference source, estimated offsets, frequency correction, and uncertainty fields.
chronyc sources -v	List sources with a legend explaining source mode and selection markers.

Tracking offsets and root delay/dispersion are shown in seconds; source samples can use suffixes such as ms or us. Frequency is reported in parts per million. Reach is an octal reachability register, not a percentage.

The concepts that matter

1. Clocks drift even when nobody changes them

A machine’s oscillator does not keep perfect time. Without correction, its clock gradually diverges from other machines. NTP exchanges timestamped messages so a client can estimate its offset from a time source and adjust its clock.

Synchronization is ongoing estimation, not a one-time setting. Virtualization, network changes, suspend/resume, and oscillator behavior can alter the correction required over time.

2. Network delay creates uncertainty

A time exchange takes time to travel in both directions. The client estimates delay and offset, but unequal outbound and return delays can bias that estimate.

Multiple samples and source selection help reject poor measurements. Stratum describes distance in the time-distribution hierarchy, not a simple accuracy score. A low-stratum source reached over a poor path is not automatically the best source for a particular client.

3. Wall time and elapsed time serve different purposes

Wall-clock time gives a calendar timestamp for logs, token expiry, and scheduled events. Timezone settings change how a timestamp is displayed, not the underlying instant.

Elapsed durations need a suitable monotonic clock so a wall-clock correction does not make a timeout run backward or jump ahead. On Linux, monotonic clocks can still differ in how suspend time is treated. Choose the clock according to the duration being measured, not merely the most familiar time API.

4. Synchronized does not mean perfectly simultaneous

A synchronization status indicates the time service’s current assessment under its rules. Residual offset and uncertainty remain. Clock agreement is useful for authentication and log correlation, but it does not establish exact causal order across machines.

A distributed request identifier or trace relationship can connect events more reliably than sorting nearly equal timestamps. Investigate source reachability and uncertainty before treating apparent timestamp inversions as proof of an application bug.

One small example

Optional: inspect an existing chrony-managed Linux host. These commands query status only; they do not set the clock, choose servers, or restart synchronization.

timedatectl status
chronyc tracking
chronyc sources -v

Compare local time with UTC and the configured timezone. In tracking, inspect the reference, leap status, system-time correction, and uncertainty fields. In sources, the legend explains which source is selected and which are rejected or unreachable; actual markers depend on current conditions.

An active NTP service alone is not proof of successful synchronization. A chronyc connection failure can mean chronyd is absent or inaccessible, even if another time service runs. Do not copy sample offsets as expected measurements: values vary continuously. This inspection cannot establish perfect time accuracy against an independent reference.

Keep this idea: Clock synchronization estimates a shared time with uncertainty; use monotonic time for durations and explicit relationships for causality.