Synchronise Linux Time Safely with ntpdate-debian

You will check an NTP time source, understand where ntpdate-debian gets its servers, and perform a one-off clock synchronisation when it is appropriate. The installed package here is ntpsec-ntpdate version 1.2.2+dfsg1-4build2. Allow about ten minutes, plus the time needed to investigate any firewall or DNS problem.

This command changes the system clock when run normally. That can affect logs, scheduled jobs, certificates and running services. The first checks below use -q, which queries without setting the clock. You need an ordinary shell for the checks and elevated privileges for a real synchronisation.

1. Check the installed command

Confirm that the wrapper and the package you are about to use are the expected ones:

$ 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...

The local manual describes ntpdate-debian as the NTP client that is equivalent to ntpdate, except that this Debian wrapper reads /etc/default/ntpsec-ntpdate by default. The option spelling shown by the installed program is the useful authority when package versions differ.

Checkpoint: if command -v finds a different path, stop and inspect it before continuing. Do not assume that a similarly named command uses the same configuration.

2. See which configuration the wrapper uses

Read the defaults file without editing it:

$ 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=""

The comments and values can differ on your host. With NTPDATE_USE_NTP_CONF=yes, the installed wrapper reads server and peer entries from /etc/ntpsec/ntp.conf when that file is readable. With that setting enabled, the NTPSERVERS value is a fallback rather than the list normally used. A DHCP-provided list under /run/ntpsec/ntpdate.dhcp can also be loaded unless IGNORE_DHCP=yes.

Do not edit this file just to make a one-off test. Configuration changes are persistent and can alter later network-start or scheduled runs. If you do need to change it, make a dated backup first and retain 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, selected address and status will vary. The useful result is a zero exit status and a response from at least one server. Capture the status immediately if you are scripting the check:

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

-q is the safety boundary in this step. It asks for the time calculation but does not set the local clock. It does not prove that a later write operation will be permitted, and it does not check every configured server.

Checkpoint: do not continue to a write operation if the query fails. Check DNS, routing and firewall policy first. A non-zero result is a connectivity or NTP selection problem, not a reason to add random servers to the configuration.

4. Decide whether a clock step is acceptable

Compare the reported offset with the work you are about to do. A clock correction can move time forwards or backwards. Review active jobs, log collection, distributed databases, authentication and any service that assumes timestamps move smoothly.

The default operation sets the time using the NTP result. The -b option forces a step, while -B requests a slew. These are operational choices, not harmless diagnostics. Use a maintenance window for a production host, tell anyone consuming its logs, and make sure you have console access if a dependent service reacts badly.

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

5. Synchronise once, with privilege

When the query is healthy and a one-off correction is justified, run the wrapper with sudo and let its configured servers remain 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 exact message vary. A zero status means the command found a server and completed its clock update. The example's documentation address is illustrative, not a server you should add to your configuration. Use the real output from your host when checking the result.

If you need an explicit server for a controlled test, pass it as an argument:

$ sudo ntpdate-debian example.ntp.invalid

On this Debian wrapper, command-line server arguments are combined with the servers it obtains from its configuration. Read the wrapper's current configuration before assuming that a named host is the only source contacted. Prefer the configured list for routine operation and use 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 output:

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 example writes temporary diagnostics to /tmp; choose a private directory if the output could reveal network details on a multi-user host. Do not put sudo into an automated check unless its privilege and prompting behaviour have been designed and tested. A monitoring check should normally remain unable to change the system clock.

7. Handle common failures

• No response or name resolution failure: test the configured names with your normal DNS and network tools, then inspect the NTP firewall path. Fix the source or connectivity before changing time.
• Permission denied during a real update: rerun the successful query as the ordinary user, then use the host's approved privilege mechanism for the actual write. Do not run the entire shell as root just to hide an unclear permission problem.
• Unexpected servers: inspect /etc/default/ntpsec-ntpdate, /etc/ntpsec/ntp.conf and the DHCP file path described above. The wrapper may be using more than the name you supplied.
• Large or surprising offset: stop and check whether the host already has another time daemon or scheduled synchronisation. Two independent time setters can fight each other.

Keep a working NTP daemon or other approved time service as the long-term solution where your distribution provides one. This wrapper is useful for a controlled one-off correction or an early-boot case, but repeatedly changing a well-connected host's clock by hand is difficult to operate safely.