How to Configure Network Time Synchronisation Delays in Ubuntu Using systemd-time-wait-sync

Modern distributed systems, cryptographic logging frameworks, database clusters (such as CockroachDB, Cassandra, and etcd), and security daemons require an accurate, monotonic clock to operate safely. If an enterprise server boots and immediately launches database services or certificate validation routines while its internal real-time clock (RTC) is unsynchronised or experiencing severe drift, transactions can become corrupted, Kerberos tickets fail, and distributed consensus breaks down. To solve this boot-ordering dilemma, modern systemd-based Linux distributions like Ubuntu provide systemd-time-wait-sync.service. This system daemon delays dependent services during startup until an NTP client has mathematically confirmed that the kernel system clock is accurately synchronised.

Role of systemd-time-wait-sync in Modern Boot Architecture

In standard systemd boot sequences, time synchronisation clients—such as systemd-timesyncd, chrony, or ntpd—launch in the background as asynchronous services. Because standard unit ordering targets like basic.target or multi-user.target do not wait for external network handshakes to finish, high-level applications frequently launch seconds before the local clock establishes lock with remote NTP stratum servers.

systemd-time-wait-sync.service introduces an authoritative synchronization gate by managing the systemd target time-sync.target:

• Target Gatekeeper: It is ordered Before=time-sync.target and Wants=time-sync.target.
• Kernel Clock Inspection: The service directly queries the kernel clock state via adjtimex() or listens for notification files in /run/systemd/timesync/synchronized.
• Execution Hold: Any downstream unit that includes After=time-sync.target and Requires=time-sync.target is blocked from starting until systemd-time-wait-sync verifies valid clock synchronization.

Verifying Service Availability on Ubuntu

On Ubuntu Server and Desktop installations, the unit definition is included in the standard systemd package. To inspect its current status, launch a terminal and run:

systemctl status systemd-time-wait-sync.service

Inspect the internal configuration and unit dependencies using systemctl cat:

systemctl cat systemd-time-wait-sync.service

The unit definition outlines its synchronization boundaries:

[Unit]
Description=Wait Until Kernel Time Synchronized
Documentation=man:systemd-time-wait-sync.service(8)
DefaultDependencies=no
Before=time-sync.target shutdown.target
Wants=time-sync.target

[Service]
Type=oneshot
ExecStart=/lib/systemd/systemd-time-wait-sync
RemainAfterExit=yes
TimeoutStartSec=infinity

Enabling and Activating systemd-time-wait-sync

By default, systemd-time-wait-sync.service is disabled on standard Ubuntu installations to minimize boot latency on workstations. To enable the synchronization gate on production servers, execute:

sudo systemctl enable systemd-time-wait-sync.service
sudo systemctl start systemd-time-wait-sync.service

Once started, verify that the daemon has confirmed clock synchronization:

systemctl status systemd-time-wait-sync.service

A successful execution reports an active, exited status (as it is a Type=oneshot unit that remains marked active once the clock is locked):

● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized
     Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; preset: enabled)
     Active: active (exited) since Sun 2026-11-08 15:35:10 UTC; 2m ago
   Main PID: 812 (code=exited, status=0/SUCCESS)

Configuring Application Dependencies on time-sync.target

Enabling the service is only effective if your time-critical applications explicitly declare their dependency on time-sync.target. For example, if you manage a database service (such as PostgreSQL or etcd), create a systemd drop-in override to bind it to the synchronization target:

sudo systemctl edit postgresql.service

Add the following ordering directives inside the override file:

[Unit]
After=time-sync.target
Wants=time-sync.target

Reload the systemd manager configuration to apply the updated ordering graph:

sudo systemctl daemon-reload

During subsequent boots, systemd will hold PostgreSQL in a queued state until systemd-time-wait-sync finishes validating network time.

Configuring Boot Timeouts to Prevent Indefinite Boot Hangs

By default, systemd-time-wait-sync.service sets TimeoutStartSec=infinity. While this guarantees clock accuracy, it can cause headless edge servers or remote branch offices to hang indefinitely during boot if physical network connectivity or DNS is down at power-on.

To prevent infinite boot blocking, configure a reasonable timeout threshold using a systemd drop-in override:

sudo systemctl edit systemd-time-wait-sync.service

Set a finite timeout (such as 30 or 60 seconds):

[Service]
TimeoutStartSec=45s

Save the file and reload the daemon:

sudo systemctl daemon-reload

If network time cannot be synchronized within 45 seconds, the service will time out, allowing system boot to proceed while recording the failure in system logs.

Verifying Kernel Clock Status and Troubleshooting

To inspect whether your active NTP client (systemd-timesyncd or chrony) is successfully updating the kernel time status flags, query timedatectl:

timedatectl status

Ensure that both NTP service: active and System clock synchronized: yes are displayed. To inspect low-level kernel clock status flags directly, check the adjtimex parameters:

adjtimex -p | grep status

If systemd-time-wait-sync fails to complete, check whether local firewall rules block outbound UDP port 123 (NTP) or if upstream NTP pools are unreachable, ensuring robust and deterministic time gating across your Ubuntu infrastructure.