Synchronise Linux Time Safely with ntpdate-debian

Run ntpdate-debian without thinking and you can step the clock mid-cron-job and take a TLS handshake down with it. This guide shows a read-only check first, then a deliberate, privileged sync when you actually need one. The installed package here is ntpsec-ntpdate version 1.2.2+dfsg1-4build2. Allow about ten minutes, plus extra if you end up chasing a firewall or DNS problem.

A normal run changes the system clock. That can knock out log ordering, scheduled jobs, certificates and anything else that assumes time moves forwards smoothly. The checks below start with -q, which queries without touching the clock. You need an ordinary shell for those, and elevated privileges only once you decide a real sync is justified.

1. Check the installed command

Confirm the wrapper and package you are about to trust:

$ command -v ntpdate-debian
/usr/sbin/ntpdate-debian
$ dpkg-query -W -f='${Package} ${Version}\n' ntpsec-ntpdate
ntpsec-ntpdate 1.2.2+dfsg1-4build2
$ ntpdate-debian -h
Usage: ntpdate [OPTIONS] HOST...

ntpdate-debian is the NTP client equivalent to ntpdate, with one Debian-specific twist: this wrapper reads /etc/default/ntpsec-ntpdate by default. When package versions differ, trust the option spelling the installed binary actually prints over any example you find online.

2. See which configuration the wrapper uses

Read the defaults file, do not edit it yet:

$ sed -n '1,160p' /etc/default/ntpsec-ntpdate
# The settings in this file are used by the program ntpdate-debian, but not
# by the upstream program ntpdate.
NTPDATE_USE_NTP_CONF=yes
NTPSERVERS="ntp.ubuntu.com"
NTPOPTIONS=""
IGNORE_DHCP=""

• NTPDATE_USE_NTP_CONF=yes makes the wrapper read server and peer entries from /etc/ntpsec/ntp.conf when that file is readable. With this on, NTPSERVERS is just a fallback, not the list you think you are querying.
• DHCP can also feed it. A DHCP-provided server list under /run/ntpsec/ntpdate.dhcp gets loaded too, unless IGNORE_DHCP=yes.
• Comments and values vary by host. Read your own copy before assuming this one matches.

Do not edit this file for a one-off test. Changes here are persistent and can alter later network-start or scheduled runs. If you genuinely need to change it, make a dated backup first and keep the old contents for recovery.

3. Query a server without changing the clock

Run a read-only query against a known NTP name:

$ ntpdate-debian -q pool.ntp.org
2026-09-25 07:40:56.434686 (+0100) +0.003660 +/- 0.008647 pool.ntp.org 185.248.188.98 s1 no-leap

The date, offset, delay, address and status will all differ on your host. What matters is a zero exit status and a reply from at least one server. Capture that status immediately if you are scripting the check:

$ ntpdate-debian -q pool.ntp.org
$ status=$?
$ printf 'query status: %s\n' "$status"
query status: 0

4. Decide whether a clock step is acceptable

• Compare the offset against the work at hand. A correction can move time forwards or backwards; review active jobs, log collection, distributed databases and authentication before you commit.
• Know your options. The default run sets the time outright. -b forces a step; -B requests a slew instead. Neither is a harmless diagnostic.
• Treat it as an operational change. Use a maintenance window on production, warn whoever consumes its logs, and make sure you have console access in case a dependent service reacts badly.

There is no general undo for a clock change. Recovery means getting a trusted time reading and setting the clock again, or restarting the host's normal time-management service through your platform's usual procedure. Do not combine -b and -B in one command while experimenting.

5. Synchronise once, with privilege

Once the query is healthy and a one-off correction is justified, run the wrapper with sudo and let its configured servers stay in the selection:

$ sudo ntpdate-debian
25 Sep 07:44:12 ntpdate[12345]: adjust time server 192.0.2.10 offset 0.003660 sec
$ printf 'sync status: %s\n' "$?"
sync status: 0

The address, process ID, offset and message all vary. A zero status means it found a server and completed the update. The documentation address in this example is illustrative only, not something to add to your own configuration; always check the real output from your own host.

Need a specific server for a controlled test? Pass it as an argument:

$ sudo ntpdate-debian example.ntp.invalid

This Debian wrapper combines command-line server arguments with the servers already in its configuration, it does not replace them. Read the current configuration before assuming a named host is the only thing being contacted. Prefer the configured list for routine work and reach for an explicit host only when you have a reason to test it.

6. Keep automation read-only until it is proven

For a monitoring or pre-flight check, use the query form and branch on the status rather than parsing human-readable text:

if ntpdate-debian -q pool.ntp.org >/tmp/ntpdate-query.out 2>/tmp/ntpdate-query.err; then
    printf '%s\n' 'NTP query succeeded'
else
    status=$?
    printf 'NTP query failed with status %s\n' "$status" >&2
    exit "$status"
fi

This writes temporary diagnostics to /tmp; use a private directory if the output could reveal network details on a shared host. Do not put sudo in an automated check unless its privilege and prompting behaviour have been designed and tested. A monitoring check should stay unable to change the system clock, full stop.

7. Handle common failures

• No response or name resolution failure: test the configured names with your normal DNS and network tools, then check the NTP firewall path. Fix the source or connectivity before touching the clock.
• Permission denied during a real update: rerun the successful query as the ordinary user, then use the host's approved privilege mechanism for the write. Do not run the whole shell as root just to paper over an unclear permission problem.
• Unexpected servers: inspect /etc/default/ntpsec-ntpdate, /etc/ntpsec/ntp.conf and the DHCP file path from step 2. The wrapper may be using more sources than you supplied.
• Large or surprising offset: stop and check whether the host already runs another time daemon or scheduled sync. Two independent time setters fighting each other is a classic own-goal.

Keep a proper NTP daemon or equivalent as the long-term solution where your distribution provides one. This wrapper suits a controlled one-off correction or an early-boot case, but repeatedly hand-adjusting a well-connected host's clock is hard to do safely at scale.