VMware ESXi and vSphere Cluster Management

Network Time Protocol (NTP) on Linux

Learn how NTP synchronizes Linux clocks, why accurate time matters, how strata work, and how to configure and verify chrony or systemd-timesyncd.

Network Time Protocol (NTP) is a network protocol and software ecosystem for synchronizing computer clocks. On Linux, an NTP client regularly compares the local clock with approved time sources and adjusts it to maintain a consistent time basis, usually Coordinated Universal Time (UTC).

NTP does more than copy a timestamp once. It measures clock drift, estimates network transmission delay, and gradually disciplines the system clock. Manual clock setting changes the time at one moment; synchronization continuously corrects the clock as it deviates.

Why Accurate Time Matters

Every computer clock gradually deviates from correct time. This deviation is called clock drift. When systems on a network have different clocks, events can appear in the wrong order even when the events occurred correctly.

• Files: A client clock ahead of a file server can make a newly saved file appear older or newer than expected.
• Backups: Incremental backup tools may miss changes or process files in an unexpected order when timestamps are inconsistent.
• Logs and monitoring: Comparing logs from several hosts becomes difficult when event timestamps do not share a common reference.
• Scheduled jobs: Cron jobs and other timers may run early, late, twice, or not at the intended time after a correction.
• Distributed services: Databases, queues, build systems, and clustered applications often use timestamps to order or expire work.
• Authentication: Kerberos tickets have validity periods. A workstation whose clock differs substantially from an authentication server may be rejected even when the credentials are correct.

Small differences can create operational confusion, and larger differences can cause security failures. Time synchronization supports security controls, but it does not replace secure configuration, authorization, encryption, or protected logs.

NTP Transport and Network Requirements

NTP normally uses UDP port 123. A client sends requests to an approved time server, receives timing information, and uses multiple measurements to estimate the correct local time. A machine configured only as a client generally needs appropriate outbound UDP/123 access and return traffic allowed by the network policy.

An NTP server that provides time to other machines has an additional responsibility: it must accept appropriate inbound UDP/123 traffic from those clients. Do not expose an internal time service to networks that do not need it.

• Permit UDP/123 between clients and approved upstream sources.
• Check DNS, routes, gateways, and firewall rules when sources cannot be reached.
• Use organization-managed time servers when policy provides them.
• Remember that an NTP client and an NTP server describe roles; the same host can be a client upstream and a server downstream.

The NTP Time-Source Hierarchy

NTP distributes time hierarchically instead of requiring every computer to contact a physical reference clock. A stratum is a number describing a source's distance from a reference time source.

Lower stratum numbers generally indicate greater proximity to the reference source, but a lower number does not automatically mean better service. Network delay, packet loss, source stability, and measurement quality also matter. Implementations compare multiple upstream sources and select reliable time while retaining alternatives for resilience.

NTP Client, Server, and Linux Implementations

NTP can refer to the protocol itself or, depending on context, to an implementation that provides synchronization. An NTP client synchronizes its own clock. An NTP server provides time to other machines.

Common Linux implementations include:

These services are not interchangeable configuration files. Select one supported time synchronization service and avoid running chronyd, systemd-timesyncd, and ntpd concurrently. Multiple daemons can compete to control the same system clock.

System Clock and Hardware Clock

The system clock is maintained by the running Linux kernel and used by applications, logs, file timestamps, and scheduled jobs. The hardware clock, also called the real-time clock (RTC), is a battery-backed clock maintained by the machine hardware or firmware while the system is powered off.

Display the current system time and timezone with:

date
timedatectl status

On systemd-based systems, timedatectl status commonly shows local time, UTC time, the configured time zone, whether an NTP service is active, and whether synchronization is reported.

Inspect the RTC with:

sudo hwclock --show

NTP disciplines the system clock. Hardware-clock updates may happen at boot or shutdown, or through an explicit administrative action. Writing the RTC manually should be deliberate because systems can be configured to interpret it as UTC or local time.

Configure a Linux NTP Client with chrony

1. Choose trusted sources

Prefer organization-managed time servers where available. Otherwise, use reputable pool sources according to local policy. Multiple independent sources improve resilience and allow the client to reject an unreliable source.

2. Add client sources

Edit the chrony configuration file used by the distribution. A basic example is:

pool pool.ntp.org iburst
server time1.example.net iburst
server time2.example.net iburst

Use approved production names instead of relying solely on this example. The iburst option requests a rapid initial series of measurements when a source is reachable, helping the host converge sooner.

3. Enable and start the service

sudo systemctl enable --now chronyd

Some distributions name the service chrony rather than chronyd. Check the package documentation or available unit names if this command does not find the service.

4. Verify synchronization

chronyc tracking
chronyc sources -v

Use the output to identify the selected source, stratum, offset, delay, reachability, and synchronization state. A newly started client may need time to collect measurements before it reports stable synchronization.

Use systemd-timesyncd as an Alternative

systemd-timesyncd is a lightweight client option on systems where it is the selected service. Configure it in /etc/systemd/timesyncd.conf:

[Time]
NTP=time1.example.net time2.example.net
FallbackNTP=pool.ntp.org

Enable it and request NTP synchronization:

sudo systemctl enable --now systemd-timesyncd
timedatectl set-ntp true
timedatectl timesync-status

Do not run systemd-timesyncd concurrently with chronyd or ntpd. The service name and available commands can vary by distribution.

Traditional ntpd Environments

Some Linux and Unix environments still use the traditional ntpd daemon. Its configuration is commonly in /etc/ntp.conf, but package and service details vary. Verify an ntpd-managed client with:

ntpq -p
ntpstat

Treat these commands as implementation-specific. Do not apply chrony configuration syntax or service commands blindly to an ntpd installation.

How to Verify Synchronization

A clock can display a plausible time without being synchronized. Verification should establish that the intended service is active, a source has been selected, measurements are usable, and the system reports a synchronized state.

With chrony, chronyc tracking reports tracking information such as the reference ID, stratum, system time offset, root delay, and synchronization state. chronyc sources -v lists candidate sources and provides source selection, reachability, offset, and delay information.

With systemd-timesyncd, use:

timedatectl status
timedatectl timesync-status

For service and log checks, use commands such as:

systemctl status chronyd
systemctl status systemd-timesyncd
ss -u -a -n
journalctl -u chronyd --since "1 hour ago"
journalctl -u systemd-timesyncd --since "1 hour ago"

If the initial clock error is large, the daemon may need to perform a controlled step correction rather than a slow adjustment. Follow organizational change procedures before forcing a major correction on a production host, because a time jump can affect applications and scheduled work.

Practical Example: File Timestamp Inconsistency

Suppose a client clock is several minutes ahead of a file server. A file created on the client can appear to have a future timestamp when viewed on the server. An incremental backup may then misclassify the file, and a build system may process files in the wrong order. Synchronized clocks do not solve every filesystem or backup problem, but they remove a major source of misleading evidence.

Practical Example: Kerberos Clock Skew

Kerberos authentication uses tickets with time-based validity periods. If a workstation clock differs too far from the authentication service, the service can reject a ticket as not yet valid or already expired. Compare UTC time and synchronization state on both hosts; do not diagnose this only by looking at local clock displays, because a timezone display can be confusing even when UTC is correct.

Troubleshoot an Unsynchronized Host

The system reports that NTP is not synchronized

1. Run timedatectl status.
2. Check the selected daemon's service status and recent logs.
3. For chrony, inspect chronyc tracking and chronyc sources -v.
4. Confirm that at least one usable upstream source is configured.
5. Confirm that only one time daemon is managing the clock.
6. Allow time for a newly started service to obtain measurements.

Sources are unreachable

• Confirm that source names resolve to expected addresses.
• Verify routing, the default gateway, and IP connectivity.
• Review firewall and network security rules for UDP/123, including return traffic as required.
• Check for incorrect server names, addresses, or an upstream outage.
• Use daemon source-status output and logs to distinguish network reachability from poor time quality.

The offset is large or the clock jumps

• Check whether the host began with a severely incorrect clock.
• On virtual machines, check hypervisor time synchronization and avoid conflicting control of the guest clock.
• Review source stability, delay, packet loss, and selected-source changes.
• Use several trustworthy sources and follow change procedures before a major correction.

The wrong source is selected or quality is poor

Review source selection, stratum, reachability, delay, and offset. A single source provides no redundancy. Add approved independent sources and prefer nearby or organization-managed sources when available.

Operational and Security Considerations

• Use trustworthy, approved upstream sources.
• Configure multiple independent sources when reliable service is important.
• Keep DNS available because pool names and server names require name resolution.
• Account for routing, UDP/123 firewall policy, intermittent connectivity, and packet loss.
• Consider virtual-machine clock behavior and prevent the hypervisor and guest daemon from fighting over the clock.
• Do not expose an internal NTP server unnecessarily; restrict clients and network access according to policy.
• Remember that synchronized time improves auditing and security monitoring but does not itself provide authentication, authorization, secure transport, or log integrity.

Exam-Relevant Summary

• NTP synchronizes clocks over a network and normally uses UDP port 123.
• It compensates for clock drift and network delay; it is not the same as setting a clock once by hand.
• UTC is the common time basis used by network time services.
• Stratum 0 is reference hardware, stratum 1 is directly connected to that hardware, and higher strata are progressively downstream.
• Lower stratum usually means closer to the reference, not automatically better.
• The system clock is distinct from the hardware clock or RTC.
• Use one time daemon at a time: chrony, systemd-timesyncd, or ntpd.
• Verify synchronization state, selected source, stratum, reachability, offset, delay, and service status.

For related study, see Network Time Protocol (NTP).