NTP and Chrony Time Synchronization on Linux

Accurate time synchronization is crucial for system logs, authentication, distributed systems, and countless other operations. In this guide, we’ll explore both NTP (Network Time Protocol) and Chrony, two powerful tools for maintaining precise system time on Linux.

Understanding Network Time Protocol (NTP)

Network Time Protocol is the standard protocol for synchronizing computer clocks across networks. It ensures that all systems maintain accurate time by periodically communicating with time servers.

The pool.ntp.org Project

The pool.ntp.org project provides a large cluster of volunteer-operated time servers that are available for public use. When you configure NTP servers like:

server 0.centos.pool.ntp.org iburst
server 1.centos.pool.ntp.org iburst
server 2.centos.pool.ntp.org iburst
server 3.centos.pool.ntp.org iburst

You’re connecting to this distributed network of servers. These entries serve two important purposes:

• Redundancy: Multiple servers ensure continuous time synchronization even if one server fails
• Load Balancing: DNS rotation spreads requests across volunteer servers, preventing overload

The iburst Option

The iburst option sends a burst of NTP requests when the client starts, dramatically speeding up initial synchronization. Without it, your system might take much longer to achieve accurate time.

Understanding Stratum Levels

NTP uses a hierarchical system called stratum to indicate distance from the reference clock and accuracy:

Stratum	Description	Example
0	High-precision timekeeping devices (atomic clocks, GPS clocks)	Not directly on network
1	Computers directly connected to Stratum 0 devices	Primary time servers
2	Servers synchronized with Stratum 1 over network	Secondary time servers
3-15	Each level synchronizes with the level above	Increasing network delay
16	Unsynchronized or invalid time source	Error condition

Key principle: Lower stratum numbers indicate higher accuracy and reliability. Most internet NTP servers (like pool.ntp.org) operate at Stratum 2 or 3.

Broadcast, Multicast, and Manycast

NTP supports three different communication methods for servers to reach clients:

Broadcast Mode

broadcast 192.168.1.255 autokey    # broadcast server

• Sends time updates to all devices on a specific local subnet
• Uses broadcast address (ending in .255)
• Clients passively receive updates without requesting
• Limited to local network segment

Multicast Mode

broadcast 224.0.1.1 autokey        # multicast server

• Sends time updates to a specific multicast group (224.0.0.0 - 239.255.255.255)
• Only devices that “joined” the multicast group receive updates
• Can traverse routers if multicast routing is enabled
• More flexible than broadcast

Manycast Mode

manycastserver 239.255.254.254     # manycast server

• A discovery mechanism where clients send requests to a multicast address
• Nearby NTP servers respond, and clients select the best ones
• Essentially “auto-discovery” for NTP servers
• Establishes regular unicast associations after discovery

Note: The autokey option enables public key cryptography for secure authentication.

Configuring Localhost and Orphan Mode

Adding Localhost as a Time Server

Adding server 127.0.0.1 to your NTP configuration enables the service to use the local system as a time server. This is particularly useful when:

• External NTP servers are unavailable
• The system needs to provide time to other devices without internet connectivity
• You want a fallback time source

Understanding Orphan Mode

The tos orphan 6 directive configures orphan mode - a survival mechanism for when all external time sources become unreachable.

How it works:

1. Normal Operation: Server synchronizes with external servers (like pool.ntp.org)
2. Network Isolation: All external time servers become unreachable (outage, firewall issues)
3. Orphan Activation: Server enters orphan mode using its own system clock
4. Continued Service: Server can still provide time to local network clients

Why Stratum 6?

Setting orphan stratum to 6 ensures:

• Client systems prefer any available Stratum 1-5 servers
• The orphaned server becomes a “last resort” time source
• Prevents clients from trusting an isolated server’s time as highly accurate

Real-world scenario: In a data center, if internet connectivity is lost:

• Without orphan mode: All servers lose time sync and clocks drift independently
• With orphan mode: One server becomes the orphan master (Stratum 6), maintaining relative time consistency within the isolated network

Important: Orphan mode maintains consistency within the network, not absolute accuracy. The local clock still drifts without external correction.

Editing NTP Configuration

Using vi Editor

To modify /etc/ntp.conf:

vi /etc/ntp.conf

Vi commands for editing:

• G - Jump to end of file
• o - Enter insert mode on new line below cursor
• Type your configuration
• Esc - Exit insert mode
• :wq - Save and quit

Adding Configuration Lines

At the end of the file, add:

server 127.0.0.1
tos orphan 6

Verifying Changes

tail -n 2 /etc/ntp.conf

This displays the last 2 lines. If you see extra blank lines, adjust: tail -n 3 /etc/ntp.conf

Applying Changes

For ntpd:

sudo systemctl enable ntpd
sudo systemctl start ntpd
sudo systemctl status ntpd

For chronyd (CentOS 7+):

sudo systemctl enable chronyd
sudo systemctl start chronyd
chronyc sources

Introduction to Chrony

Chrony is a modern time synchronization system that has become the default on modern Linux distributions (CentOS 7+, RHEL 7+, Fedora).

Components

• chronyd: The daemon - a background process maintaining time accuracy
• chronyc: Command-line interface for controlling and querying chronyd
• Configuration: /etc/chrony.conf

What is a Daemon?

A daemon is a background process not owned by any user, typically starting at boot. Think of it like a teenager with limited states:

• Sleeping: Idle, waiting for something to do (most of the time)
• Waking: Becomes active when triggered
• Working: Performs assigned tasks (like synchronizing time)
• Waiting: Must wait for dependencies before working

Chrony Time Sources

Chronyd can obtain reference time from multiple sources:

1. NTP Servers: Remote servers accessed over network (most common)
2. Manual Input: Time set manually via chronyc commands
3. Hardware Clock (RTC): Battery-powered clock chip on motherboard
4. GPS Receivers: For high-precision requirements
5. Local Reference: System’s own clock (similar to orphan mode)

Chrony vs NTP Comparison

Feature	Chrony (chronyd)	NTP (ntpd)
Synchronization Speed	Faster initial sync	Slower, more gradual
Intermittent Connectivity	Excellent - designed for it	Poor - needs continuous connection
Virtual Machines	Better suited	Can struggle with VM clock adjustments
Resource Usage	Lower (lightweight)	Higher (more processes)
Clock Adjustment	Handles large corrections	Panics with differences >1000s
Systems That Suspend	Handles well (laptops)	Not designed for suspend/resume
Default on Modern Linux	Yes (CentOS/RHEL 7+)	No (legacy systems)
Broadcast/Multicast Server	Limited support	Full support

When to Use Chrony

• Modern Linux distributions (CentOS 7+, RHEL 7+, Fedora)
• Systems with intermittent network connectivity (laptops, mobile devices)
• Virtual machines and cloud instances
• Systems that frequently suspend or hibernate
• Most general-purpose servers and workstations

When to Use NTP (ntpd)

• Legacy systems (older distributions)
• When acting as a broadcast or multicast time server
• Specialized high-precision time server requirements
• Compatibility with older NTP infrastructure
• Stratum 1 time servers directly connected to reference clocks

Monitoring Time Synchronization

Using chronyc tracking

The chronyc tracking command displays current synchronization status:

chronyc tracking

Example output:

Reference ID    : 6C3D49F3 (helium.constant.com)
Stratum         : 3
Ref time (UTC)  : Sat Nov 16 13:15:29 2019
System time     : 0.000111187 seconds slow of NTP time
Last offset     : -0.00025628 seconds
RMS offset      : 0.000360095 seconds
Frequency       : 39.187 ppm slow
Residual freq   : -0.005 ppm
Skew            : 0.149 ppm
Root delay      : 0.014869913 seconds
Root dispersion : 0.029435221 seconds
Update interval : 64.9 seconds
Leap status     : Normal

Key fields explained:

• Reference ID: Current time server (helium.constant.com)
• Stratum: Distance from reference clock (3 = good)
• System time: How far behind/ahead of NTP time (0.11ms slow - excellent)
• Frequency: Clock drift rate (39.187 ppm = loses 3.4 seconds/day, automatically compensated)
• Root delay: Network round-trip delay (14.9ms - reasonable)
• Leap status: Leap second pending? (Normal = no)

Good output indicators:

• System time offset close to zero (within milliseconds)
• Low RMS offset (sub-millisecond)
• Stratum 2-4 for typical systems
• Stable frequency value
• Low skew (under 1 ppm)
• Leap status “Normal”

Using chronyc sources

View all time sources and their status:

chronyc sources

Example output:

MS Name/IP address          Stratum Poll Reach LastRx Last sample
============================================================================
^+ web.vranetworks.net           3   8  377    124   -962us[ -963us] +/-  58ms
^- blue.1e400.net                3   7  377    121  +4412us[+4411us] +/-  79ms
^+ 198.255.68.106                2   8  377    251  +1409us[+1407us] +/-  72ms
^* callisto.netbunker.org        2   8  377    120   -375us[ -375us] +/-  27ms

State indicators:

• * = Currently selected sync source (best)
• + = Acceptable source, combined with selected
• - = Acceptable but not currently used
• ? = Unreachable or unusable
• x = False ticker (inconsistent time)
• ~ = Too variable (high jitter)

Other fields:

• Stratum: Lower is better (2 > 3)
• Poll: Polling interval (8 = 2^8 = 256 seconds)
• Reach: 377 (octal) = 11111111 (binary) = perfect connectivity
• Last sample: Time offset and measurement error

Tip: All sources showing Reach 377 indicates perfect connectivity to time servers.

Using timedatectl

The timedatectl command provides comprehensive system time information:

timedatectl

Example output:

      Local time: Tue 2020-01-07 23:53:42 EST
  Universal time: Wed 2020-01-08 04:16:27 UTC
        RTC time: Wed 2020-01-08 04:16:27 
       Time zone: America/New_York (EST, -0500)
     NTP enabled: yes
NTP synchronized: yes
 RTC in local TZ: yes
      DST active: no
 Last DST change: DST ended at
                  Sun 2019-11-03 01:59:59 EDT
                  Sun 2019-11-03 01:00:00 EST
 Next DST change: DST begins (the clock jumps one hour forward) at
                  Sun 2020-03-08 01:59:59 EST
                  Sun 2020-03-08 03:00:00 EDT

Important fields:

• Local time: Current time in local timezone
• Universal time: Same moment in UTC (global standard)
• RTC time: Hardware clock time (battery-powered)
• Time zone: IANA identifier and UTC offset
• NTP enabled/synchronized: Both should be “yes”
• RTC in local TZ: “no” recommended for Linux-only systems
• DST active: Daylight saving time status

Common timedatectl commands:

# Set timezone
timedatectl set-timezone America/New_York

# Enable NTP synchronization
timedatectl set-ntp true

# Set RTC to use UTC (recommended)
timedatectl set-local-rtc 0

# List all timezones
timedatectl list-timezones

Warning: Having “RTC in local TZ: yes” can cause DST-related issues. Set RTC to UTC with timedatectl set-local-rtc 0 for Linux-only systems.

Configuration File Locations

Service	Configuration File	Purpose
ntpd	/etc/ntp.conf	NTP daemon configuration
chronyd	/etc/chrony.conf	Chrony daemon configuration

Both are text-based files located in /etc/, following the Linux Filesystem Hierarchy Standard (FHS). This makes them:

• Easy to edit and version control
• Accessible to system administrators
• Consistent with Linux/Unix conventions

Best Practices

1. Use multiple time sources for redundancy (3-4 servers recommended)
2. Configure orphan mode for network isolation scenarios
3. Choose Chrony for modern systems unless specific NTP features required
4. Set RTC to UTC on Linux-only systems
5. Monitor synchronization status regularly with chronyc tracking
6. Verify time sources are reachable with chronyc sources
7. Enable NTP synchronization at boot with systemd

Troubleshooting Common Issues

Time Not Synchronizing

# Check service status
systemctl status chronyd

# Check sources
chronyc sources

# Check tracking
chronyc tracking

# Verify firewall allows NTP (UDP port 123)
firewall-cmd --list-all

Large Time Offset

If system time is significantly off:

# Manually sync time (requires stopping chronyd)
sudo systemctl stop chronyd
sudo chronyd -q 'server pool.ntp.org iburst'
sudo systemctl start chronyd

Unreachable Time Servers

# Test connectivity
ping pool.ntp.org

# Check DNS resolution
nslookup pool.ntp.org

# Try different server pools
# Edit /etc/chrony.conf and change to different region
# Example: server us.pool.ntp.org iburst

Conclusion

Accurate time synchronization is fundamental to modern computing infrastructure. Whether you choose traditional NTP or modern Chrony, understanding these tools ensures your systems maintain precise time for logging, security, distributed systems, and compliance requirements.

For most modern Linux deployments, Chrony offers the best balance of speed, efficiency, and reliability. However, NTP remains valuable for legacy systems and specialized scenarios requiring broadcast/multicast time distribution.

By following the configurations and monitoring practices outlined in this guide, you’ll maintain accurate, reliable time synchronization across your Linux infrastructure.

Additional Resources

• Chrony Documentation
• NTP Pool Project
• RFC 5905 - Network Time Protocol Version 4
• Red Hat System Administrator’s Guide - Time Synchronization

---