Linux systemd-timesyncd NTP Synchronization Guide

The Linux operating system maintains precise system clocks using various time synchronization services, with systemd-timesyncd serving as the standard lightweight alternative to comprehensive daemons like Chrony or NTPd. This article provides an overview of how systemd-timesyncd functions as a Simple Network Time Protocol (SNTP) client, its architectural advantages for everyday computing and embedded devices, how to configure its settings, and the commands required to monitor and manage time synchronization directly through systemd.

Understanding systemd-timesyncd

systemd-timesyncd is a built-in system daemon provided by the systemd suite. Unlike full NTP implementations such as ntpd or chrony, which can act as both NTP servers and clients while handling complex multi-source algorithms, systemd-timesyncd is strictly a client-side implementation. It utilizes the Simple Network Time Protocol (SNTP, RFC 4330), making it exceptionally lightweight in terms of memory footprint, CPU utilization, and network traffic.

Its primary purpose is to synchronize the local system clock with remote NTP servers without the complexity of managing server-grade time-distribution infrastructure. This makes it the default time-synchronization tool on modern distributions like Ubuntu, Debian, and Arch Linux for desktop, cloud instances, and resource-constrained devices like the Raspberry Pi.

Core Mechanisms and Operation

systemd-timesyncd operates through three key mechanisms:

  1. SNTP Polling: The daemon periodically sends unicast UDP requests on port 123 to designated NTP servers. Because it does not continuously track drift across numerous complex server pools simultaneously, it consumes minimal network and system resources.
  2. Clock Discipline (Slewing and Stepping): When a time delta is detected, the service adjusts the local clock. For small offsets, it uses system calls like adjtimex to gradually adjust the clock rate (slewing), preventing sudden temporal jumps that could corrupt logs or database transactions. For large discrepancies, it steps the clock directly to the correct time.
  3. Monotonic File Modification Tracking: On devices lacking a hardware Real-Time Clock (RTC) with battery backup, system reboots can cause the clock to reset to an epoch or earlier date. systemd-timesyncd mitigates this by touching a local file on disk (/var/lib/systemd/timesync/clock) during runtime and shutdown. Upon boot, the service reads the timestamp of this file to ensure the system clock never moves backward relative to the last recorded shutdown time until network connectivity is established.

Configuring systemd-timesyncd

Configuration is managed through a single plain-text file located at /etc/systemd/timesyncd.conf or via drop-in files in /etc/systemd/timesyncd.conf.d/.

A standard configuration file contains the following directives under the [Time] section:

[Time]
NTP=0.pool.ntp.org 1.pool.ntp.org
FallbackNTP=time.cloudflare.com time.google.com
RootDistanceMaxSec=5
PollIntervalMinSec=32
PollIntervalMaxSec=2048

After editing the configuration, apply the changes by restarting the service:

sudo systemctl restart systemd-timesyncd

Management and Verification with timedatectl

The primary user interface for systemd-timesyncd is the timedatectl utility.

To enable and activate network time synchronization:

sudo timedatectl set-ntp true

To verify the current time settings, status, and synchronization state:

timedatectl

The output indicates whether the service is active, if the clock is synchronized, and the current state of the RTC.

For detailed synchronization metrics provided directly by systemd-timesyncd, run:

timedatectl timesync-status

This command outputs crucial diagnostic data, including:

Limitations

While ideal for standard computing environments, systemd-timesyncd is not designed for environments requiring microsecond-level accuracy, time-serving functionality across a local subnet, or support for hardware timestamping and PPS (Pulse Per Second) signals. In scenarios requiring high-precision timekeeping or complex multi-server redundancy, standard NTP daemons such as chrony should be deployed instead.