Time synchronization in Ubuntu 24 ensures your system clock stays accurate by connecting to Network Time Protocol (NTP) servers, preventing authentication failures, log confusion, and database inconsistencies that plague systems with drifting clocks. This guide walks you through configuring both systemd-timesyncd and chrony, troubleshooting common sync issues, and implementing best practices for production environments where precise timing matters for distributed applications, security protocols, and compliance requirements.

How Time Synchronization Works in Ubuntu 24

Ubuntu 24 uses systemd-timesyncd as the default time synchronization daemon, which implements SNTP (Simple Network Time Protocol) for basic time correction. The service connects to time servers, calculates clock drift, and gradually adjusts your system time to prevent sudden jumps that could break running applications.

The synchronization process works through these steps:

• Query configured NTP servers for current time
• Calculate offset between local and remote time
• Apply gradual corrections using clock slewing
• Monitor drift rates and adjust polling intervals
• Fall back to alternative servers if primary fails

systemd-timesyncd stores drift information in /var/lib/systemd/timesync/clock to maintain accuracy between reboots, but lacks advanced features like hardware clock synchronization or serving time to other systems.

Setting Up systemd-timesyncd

Check your current time synchronization status first:

timedatectl status

You’ll see output showing whether NTP synchronization is active. If “NTP service” shows “inactive”, enable it:

sudo timedatectl set-ntp true

Configure time servers by editing /etc/systemd/timesyncd.conf:

sudo nano /etc/systemd/timesyncd.conf

Add your preferred NTP servers:

[Time]
NTP=0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org
FallbackNTP=ntp.ubuntu.com
RootDistanceMaxSec=5
PollIntervalMinSec=32
PollIntervalMaxSec=2048

Restart the service to apply changes:

sudo systemctl restart systemd-timesyncd
sudo systemctl enable systemd-timesyncd

Verify synchronization status:

systemctl status systemd-timesyncd
timedatectl timesync-status

The timesync-status command shows detailed information including server details, poll intervals, and sync accuracy.

Installing and Configuring Chrony

For environments requiring more precise time synchronization or additional features, chrony offers better performance and flexibility than systemd-timesyncd:

sudo apt update
sudo apt install chrony

Installing chrony automatically disables systemd-timesyncd to prevent conflicts. Configure chrony by editing /etc/chrony/chrony.conf:

sudo nano /etc/chrony/chrony.conf

Basic configuration for most use cases:

# Use public NTP servers
pool 2.ubuntu.pool.ntp.org iburst
pool 0.pool.ntp.org iburst
pool 1.pool.ntp.org iburst

# Record drift in driftfile
driftfile /var/lib/chrony/chrony.drift

# Enable kernel synchronization
rtcsync

# Step time on start if offset > 1 second
makestep 1.0 3

# Enable NTP client access from local network
allow 192.168.0.0/16
allow 10.0.0.0/8

# Serve time even if not synchronized
local stratum 10

Restart chrony and check status:

sudo systemctl restart chrony
sudo systemctl enable chrony
chrony sources -v
chronyc tracking

The “sources” command shows all configured time sources with their status, while “tracking” displays current synchronization details including system clock error and drift rate.

Real-World Configuration Examples

Here are configurations for common deployment scenarios:

High-Availability Web Servers:

# /etc/chrony/chrony.conf for load-balanced servers
pool time.cloudflare.com iburst maxsources 4
pool time.google.com iburst maxsources 2

# Aggressive initial sync
makestep 0.1 3
maxupdateskew 100.0

# Log time corrections
logdir /var/log/chrony
log tracking measurements statistics

Database Clusters:

# Stricter time requirements for database consistency
pool ntp.ubuntu.com iburst maxsources 4
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst

# Minimal time steps to prevent transaction issues
makestep 0.01 1
maxslewrate 500.0
corrtimeratio 3.0

Internal Time Server:

# Server configuration to provide time to local network
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst

# Allow local network access
allow 192.168.1.0/24
allow 10.0.0.0/8

# Provide time even when not fully synced
local stratum 8
smoothtime 400 0.001

Comparison: systemd-timesyncd vs Chrony vs ntpd

Feature	systemd-timesyncd	Chrony	ntpd
Resource Usage	Very Low	Low	Medium
Accuracy	±100ms typical	±1ms typical	±10ms typical
Network Interruption Handling	Basic	Excellent	Good
Hardware Clock Sync	Basic	Advanced	Advanced
Time Server Capability	No	Yes	Yes
Configuration Complexity	Simple	Moderate	Complex
Virtual Machine Support	Limited	Excellent	Good

Performance benchmarks show chrony achieving microsecond accuracy on stable networks, while systemd-timesyncd typically maintains millisecond accuracy sufficient for most applications. Memory usage averages 2MB for systemd-timesyncd, 4MB for chrony, and 8MB for ntpd.

Troubleshooting Common Issues

Time Not Synchronizing:

Check if multiple time services are conflicting:

systemctl status systemd-timesyncd
systemctl status chrony
systemctl status ntp

Only one should be active. Disable conflicting services:

sudo systemctl disable --now systemd-timesyncd

Firewall Blocking NTP:

NTP uses UDP port 123. Configure UFW if enabled:

sudo ufw allow out 123/udp

Large Time Offsets:

If your clock is severely wrong, automatic sync might fail. Set approximate time manually first:

sudo timedatectl set-time "2024-12-19 10:30:00"

Virtual Machine Time Issues:

VMs often need special handling. For VMware guests:

# Disable periodic sync, let NTP handle it
echo 'disable_timesync=TRUE' >> /etc/vmware-tools/tools.conf

For KVM/QEMU, ensure the host uses a stable time source and consider using PTP instead of NTP for sub-millisecond accuracy.

Debugging with Logs:

Monitor synchronization activity:

# systemd-timesyncd logs
journalctl -u systemd-timesyncd -f

# chrony logs
journalctl -u chrony -f
tail -f /var/log/chrony/tracking.log

Best Practices and Security Considerations

Time Server Selection:

• Use geographically close NTP pool servers for better accuracy
• Configure multiple servers to handle outages
• Prefer stratum 1 or 2 servers for critical applications
• Consider local time servers for air-gapped networks

Security Hardening:

Restrict chrony configuration access:

sudo chmod 644 /etc/chrony/chrony.conf
sudo chown root:root /etc/chrony/chrony.conf

Monitor for time attacks by logging large corrections:

# Add to chrony.conf
logchange 0.1
mailonchange root@localhost 0.5

Monitoring and Alerting:

Create a monitoring script for time drift:

#!/bin/bash
# /usr/local/bin/check-time-sync.sh
OFFSET=$(chronyc tracking | grep "System time" | awk '{print $4}')
THRESHOLD=0.1

if (( $(echo "$OFFSET > $THRESHOLD" | bc -l) )); then
    echo "Time offset ${OFFSET}s exceeds threshold"
    exit 1
fi

echo "Time sync OK: ${OFFSET}s offset"
exit 0

Add to crontab for regular checks:

*/5 * * * * /usr/local/bin/check-time-sync.sh

High Availability Setup:

For mission-critical systems, configure multiple time sources with different network paths and consider hardware solutions like GPS time servers for environments where internet connectivity is unreliable.

Time synchronization becomes critical when running distributed databases, certificate validation, log correlation across multiple servers, or meeting regulatory compliance requirements. Test your configuration thoroughly, especially after system updates or network changes, since even small timing issues can cascade into major application failures.

For additional technical details, consult the official Chrony documentation and systemd-timesyncd manual for advanced configuration options.

---

---

This article incorporates information and material from various online sources. We acknowledge and appreciate the work of all original authors, publishers, and websites. While every effort has been made to appropriately credit the source material, any unintentional oversight or omission does not constitute a copyright infringement. All trademarks, logos, and images mentioned are the property of their respective owners. If you believe that any content used in this article infringes upon your copyright, please contact us immediately for review and prompt action.

This article is intended for informational and educational purposes only and does not infringe on the rights of the copyright owners. If any copyrighted material has been used without proper credit or in violation of copyright laws, it is unintentional and we will rectify it promptly upon notification. Please note that the republishing, redistribution, or reproduction of part or all of the contents in any form is prohibited without express written permission from the author and website owner. For permissions or further inquiries, please contact us.