systemd-timesyncd is a surprisingly robust and often overlooked NTP client that’s built right into systemd.
Let’s see it in action. Imagine you’ve just spun up a fresh Ubuntu server and want to ensure its clock is accurate.
sudo nano /etc/systemd/timesyncd.conf
Here’s a minimal timesyncd.conf that’s ready to go:
[Time]
NTP=0.ubuntu.pool.ntp.org 1.ubuntu.pool.ntp.org
FallbackNTP=ntp1.aliyun.com ntp2.aliyun.com
This configuration tells systemd-timesyncd to query 0.ubuntu.pool.ntp.org and 1.ubuntu.pool.ntp.org first. If those servers aren’t reachable, it falls back to ntp1.aliyun.com and ntp2.aliyun.com.
Now, let’s apply the changes and check the status:
sudo systemctl restart systemd-timesyncd
sudo systemctl status systemd-timesyncd
You’ll see output indicating it’s active and running. The key piece of information is the synchronization status. Look for lines like:
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2023-10-27 10:30:00 UTC; 1min ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 1234 (systemd-timesyncd)
Status: "Synchronized to time server 1.ubuntu.pool.ntp.org (XX.XX.XX.XX)."
Tasks: 1 (limit: 4915)
Memory: 1.3M
CPU: 5ms
CGroup: /system.slice/systemd-timesyncd.service
└─1234 /lib/systemd/systemd-timesyncd
The line Status: "Synchronized to time server 1.ubuntu.pool.ntp.org (XX.XX.XX.XX)." is your confirmation. The XX.XX.XX.XX will be the actual IP address of the NTP server it’s currently synced with.
systemd-timesyncd is designed to be a client-only NTP daemon, meaning it synchronizes the local system clock to an external NTP server but does not act as an NTP server for other clients on the network. This simplifies its configuration and reduces its attack surface. It operates by periodically querying NTP servers and adjusting the local clock using a sophisticated algorithm that minimizes clock drift and corrects for network latency. It also leverages the kernel’s clock adjustment capabilities to make smooth, incremental changes rather than abrupt jumps, which can disrupt time-sensitive applications.
The FallbackNTP directive is crucial for resilience. If your primary NTP servers are temporarily unavailable due to network issues or maintenance, systemd-timesyncd will seamlessly switch to the fallback servers. This ensures continuous time synchronization even in the face of transient network problems.
A common point of confusion is that systemd-timesyncd is often enabled by default on many Linux distributions, but it might not be configured with specific NTP servers. If you don’t explicitly set NTP or FallbackNTP in timesyncd.conf, it will attempt to use the IPv4 Link-Local Address 169.254.169.254, which is often used by cloud providers for metadata services, including time synchronization. While this works in many cloud environments, it’s generally better practice to specify public NTP pools or your organization’s internal NTP servers for more reliable and consistent timekeeping.
The systemd-timesyncd service also plays nicely with DHCP. If a DHCP server provides NTP server information (via DHCP option 42), systemd-timesyncd will automatically use those servers. This is a powerful feature for dynamic network environments where you don’t want to manually manage NTP configurations on each client. However, if you have explicitly configured NTP or FallbackNTP in timesyncd.conf, those settings will take precedence over DHCP-provided servers.
If you’re troubleshooting, the journalctl -u systemd-timesyncd command is your best friend. It will show you detailed logs of systemd-timesyncd’s operations, including connection attempts, synchronization successes, and any errors encountered. This is invaluable for diagnosing why your system might not be syncing.
The next step after ensuring your system clock is accurate is often configuring applications to rely on this synchronized time, or setting up chrony if you need more advanced NTP features like acting as a server or handling highly demanding synchronization scenarios.