Network Time Protocol (NTP) on Linux
Learn how NTP synchronizes Linux clocks, how stratum levels work, and how to inspect, configure, verify, and troubleshoot chrony or ntpd.
Network Time Protocol (NTP) synchronizes computer clocks across IP networks. On Linux, an NTP client contacts one or more upstream time servers, compares time measurements, and gradually disciplines the operating system clock. This keeps timestamps consistent even though every computer clock experiences clock drift, the gradual difference between a local clock and an accurate reference.
NTP is more than manually setting the date once. Manual adjustment changes the clock at one moment; synchronization continuously measures the clock and corrects it as it drifts.
This lesson assumes basic Linux command-line skills, administrative privileges, and familiarity with IP addresses, DNS, UDP, firewalls, and systemctl. See Linux for related administration topics.
Why Accurate Time Matters
Consistent time is an operational and security requirement, not merely a convenience.
- Files: A file server and a client with different clocks can produce confusing modification times. A file may appear to have been modified before it was created, or a client-side copy may appear newer than the server copy.
- Logs and monitoring: Events collected from different hosts are difficult to correlate when their timestamps disagree.
- Scheduled jobs and backups: Incorrect time can cause jobs to run early, late, twice, or not at all. Backup retention and snapshot ordering can also be affected.
- Distributed applications: Services use timestamps to order events, expire data, coordinate retries, and detect stale messages.
- Authentication: Kerberos allows only limited clock skew between clients and authentication servers. Valid credentials may be rejected when clocks differ too much.
- Auditing and incident investigation: Reliable timestamps help establish the sequence of actions and events.
- Certificates and security controls: Certificate validity periods, tokens, leases, and other time-sensitive controls depend on a trustworthy clock.
How NTP Works
NTP normally uses UDP port 123. A Linux client queries one or more upstream servers, measures the timing of responses, and disciplines its local system clock.
The client does not blindly accept the first timestamp it receives. An NTP implementation evaluates multiple sources, network delay, measurement variation called jitter, reachability, and source quality. It selects suitable sources and combines measurements to reduce the effect of a faulty or slow server.
The measured difference between the local clock and a source is the offset. The network round-trip time involved in obtaining a sample is the delay. A source with low offset alone is not necessarily the best source if it is unreliable or unreachable at other times.
After initial synchronization, NTP normally adjusts the clock gradually, a process often called slewing. Gradual correction avoids making timestamps jump suddenly. When the error is large, the implementation may perform a step adjustment, depending on its configuration and policies. A severely incorrect clock can therefore need a controlled manual correction before synchronization succeeds.
NTP Stratum Hierarchy
Stratum describes a source's distance from a reference clock in the NTP hierarchy. It is not a direct score of server quality. A lower numerical stratum generally means fewer synchronization hops, but reachability, reliability, network conditions, and configuration are also important.
Most organizations and end systems should use appropriate upstream servers, such as organization-approved internal time servers or suitable public pool servers. They should not normally query primary reference-connected servers directly. Internal NTP servers can reduce external dependency and provide one consistent organizational time source.
Linux Time Concepts
System Clock and Hardware Clock
The system clock is maintained by the running Linux kernel and is used by processes, filesystems, logs, and services. The hardware clock, also called the RTC, is maintained by the machine's hardware or firmware while the system is powered off.
During boot, Linux reads the hardware clock and uses it to initialize the system clock. Once running, an NTP service disciplines the system clock. The hardware clock may later be updated from the system clock, but that is separate from ongoing network synchronization.
Use care with hwclock --systohc while a time daemon is active. Manually changing the hardware clock does not configure an NTP client.
UTC, Local Time, and Time Zones
UTC, or Coordinated Universal Time, is the common basis for server clocks. Linux servers commonly keep the hardware clock in UTC, while desktop systems may use a local-time hardware clock for compatibility with other operating systems.
A time zone determines how UTC is displayed as local time and how local input is interpreted. If synchronization is healthy but displayed local time is wrong, inspect the time zone rather than changing NTP settings.
Inspecting Current Time and Synchronization
date
date -u
hwclock --show
timedatectl status
timedatectl timesync-statusdate displays local time and date -u displays UTC. hwclock --show reads the hardware clock. timedatectl status shows the time zone, system clock, RTC mode, NTP setting, and synchronization state where supported. timedatectl timesync-status shows details for the systemd time-sync service when that service and the systemd version support the command.
Configuring a Linux NTP Client with chrony
chrony is a commonly used modern Linux NTP implementation. Its background service is usually called chronyd, and its administration client is chronyc.
Select trustworthy and authorized sources. In an organization, use internal servers such as the examples below. For standalone systems, use suitable public pool servers according to local policy.
server ntp1.example.internal iburst
server ntp2.example.internal iburst
server ntp3.example.internal iburstAdd the server lines to the chrony configuration. The location varies by distribution; common locations are /etc/chrony.conf and /etc/chrony/chrony.conf. The iburst option requests a short burst of measurements when a source first becomes reachable, speeding initial sampling.
sudo systemctl enable --now chronyd
sudo systemctl restart chronyd
sudo systemctl status chronyd
chronyc sources -v
chronyc trackingSome distributions use a different unit name, such as chrony. Check the installed package and service name if chronyd is not found.
Configuring a Traditional ntpd Client
ntpd is the traditional NTP daemon and remains present on some systems. Its configuration file is commonly /etc/ntp.conf, but service naming varies by distribution and installation.
server ntp1.example.internal iburst
server ntp2.example.internal iburst
server ntp3.example.internal iburstsudo systemctl enable --now ntpd
sudo systemctl restart ntpd
sudo systemctl status ntpd
ntpq -p
ntpstatUse the service name supplied by the operating system. Do not run chrony and ntpd as competing clock-disciplining daemons.
Other Linux Time Services
systemd-timesyncd is a lightweight systemd time synchronization service available on some distributions. It may be sufficient for clients that need basic synchronization, while chrony or ntpd is often selected for more advanced client or server requirements.
Service, Network, and Firewall Requirements
A client needs DNS resolution and outbound UDP port 123 access to its configured sources. An NTP server that accepts client requests needs inbound UDP port 123, in addition to its own upstream access.
systemctl list-unit-files | grep -E 'chronyd|ntpd|systemd-timesyncd'
timedatectl status
getent hosts ntp1.example.internal
ss -uan | grep ':123'
firewall-cmd --list-services
ufw statusThe firewall commands are distribution-dependent. firewall-cmd is commonly associated with firewalld, while ufw is common on Ubuntu-based systems. A client does not normally need to expose an NTP listening service to the network merely to make outbound requests.
Verifying Sources and Statistics
Verification should establish three facts: a configured source is reachable, the implementation selected a suitable source, and the local clock is synchronized.
- In
chronyc sources -v, selection markers identify preferred or currently selected sources. Reachability and source state show whether samples are arriving. - In
chronyc tracking, inspect the reference ID, stratum, system time offset, root delay, root dispersion, and leap status. - In
ntpq -p, a selection marker such as*commonly identifies the current peer, while columns include stratum, reachability, delay, offset, and jitter. Exact formatting depends on the implementation. - In
timedatectl status, check whether the system reports that the clock is synchronized and whether an NTP service is active.
Offset should generally remain small for a healthy client, but acceptable values depend on the environment. Delay represents network timing. Jitter represents variation in measurements; high jitter reduces confidence in a source. A low stratum is useful, but it does not compensate for an unreachable or unstable source.
Troubleshooting NTP
“NTP is not synchronized”
- Check
timedatectl statusand the relevant service status. - Inspect configured sources with
chronyc sources -vorntpq -p. - Confirm that configured hostnames resolve with
getent hosts. - Check routing, outbound UDP 123 access, and firewall policy.
- Review service logs and correct invalid configuration.
- If the initial clock error is excessive, make a controlled temporary correction or use the implementation's documented initial-step procedure. Restore NTP synchronization immediately afterward.
No Source Is Selected
All sources may be unreachable, incorrectly named, unsuitable, or affected by excessive delay or jitter. Verify every address, configure multiple reliable sources, and compare reachability and status markers. Multiple sources are important because one unavailable or faulty server should not stop synchronization.
Authentication Fails Because of Clock Skew
Compare UTC time on the client and authentication server. Restore synchronization before retrying Kerberos authentication. Ensure that related systems use a consistent upstream design. A time daemon that has not yet obtained a valid source cannot correct a Kerberos failure by itself.
Time Changes or Oscillates
Look for multiple active daemons, manual time-setting scripts, configuration-management jobs, or virtualization guest tools that also adjust the clock. Choose one primary clock-disciplining mechanism. On virtual machines, coordinate hypervisor time synchronization with the guest NTP service rather than allowing both mechanisms to make conflicting corrections.
Local Time Is Wrong but Synchronization Is Healthy
Compare date and date -u, then inspect timedatectl status. If UTC is correct and local time is wrong, correct the time zone. This is a display and interpretation problem, not necessarily an NTP problem.
Security and Operational Practices
- Use trusted, authorized time sources. Untrusted time data can corrupt logs, interfere with authentication, invalidate certificates, or affect time-sensitive security controls.
- Configure multiple independent upstream sources rather than depending on one server.
- Use internal NTP servers when possible to reduce external dependency and give the organization a consistent time source.
- For environments requiring stronger source validation, consider deployment-dependent NTP authentication or Network Time Security.
- Restrict inbound UDP 123 to approved clients when operating an internal NTP server, and avoid exposing an unnecessary public service.
- Monitor synchronization state, offset, reachability, and source changes as part of normal operations.
Clock Relationship Summary
The relationship between the clocks and services can be summarized as follows:
- The hardware clock supplies an initial value during boot.
- The Linux kernel maintains the running system clock.
- The NTP client, such as chronyd or ntpd, compares the system clock with upstream sources and disciplines it.
- The time zone converts the synchronized time basis into displayed local time.
- The hardware clock may be written from the system clock when explicitly requested or as configured by the operating system.
Quick Administration Checklist
- Choose approved, redundant upstream sources.
- Configure exactly one primary time synchronization daemon.
- Allow outbound UDP 123 for a client, or inbound UDP 123 when hosting an NTP server.
- Enable and start the service.
- Check source selection and synchronization statistics.
- Confirm UTC, local time zone, and hardware-clock policy.
- Investigate large offsets, high jitter, unreachable sources, and competing clock adjusters.
For command-line fundamentals, see Bourne Again Shell Bash. For broader filesystem administration, see File Structure In Linux.