Home Server & Self-Hosting

Time Synchronization on a Debian Home Server - Give Logs and Services a Shared Clock

Written by Adam Muiz Updated: 07 Sep 2026 10 min read
Time Synchronization on a Debian Home Server - Give Logs and Services a Shared Clock

A home server can display the right hour and still have an unreliable clock. The timezone may be correct while network synchronization is failing. A time service may be running while its source is unreachable. Two machines may each look reasonable in isolation yet disagree enough to make a shared incident timeline confusing.

The useful question is therefore not simply, “What time does the server show?” It is: where did that time come from, how recently was it checked, and what evidence says the clock is still trustworthy?

This article presents a read-only audit for an ordinary Debian home server. It compares systemd-timesyncd and chrony without assuming either one is installed, and it stays within normal server operations rather than precision timing. It does not claim a measured result from Adam's server or prescribe one accuracy target for every workload.

Why a Shared Timeline Matters

Clock synchronization can seem cosmetic until several systems describe the same event. A reverse proxy records a request, an application records an error, a database records a write, and a firewall records a connection. If their clocks disagree, sorting the lines by timestamp may produce a story that never happened.

The Debian Administrator's Handbook makes this operational point directly: synchronized machines make it easier to cross-reference logs and reconstruct the chronology of an attack. Accurate wall time also matters to software that evaluates time windows, including certificate validity and scheduled work. The exact tolerance, however, belongs to the application. A personal blog and a distributed database do not automatically need the same timing guarantees.

NTP is not a promise that every clock becomes perfectly correct. RFC 5905 describes measurements and algorithms for estimating offset, network delay, dispersion, and jitter, then selecting and combining suitable sources to discipline a system clock. Those estimates carry uncertainty. Network congestion, asymmetric routes, a faulty source, or a disconnected client can all weaken the result.

Separate Four Things That Often Get Mixed Together

Timezone

A timezone controls how a timestamp is displayed to a person. Changing from UTC to Asia/Jakarta changes the representation, not whether the underlying clock is synchronized. A correct timezone with an incorrect system clock still produces incorrect local time.

Real-time clock and system clock

A typical machine has a hardware real-time clock (RTC) that can retain a rough time across shutdowns, and an operating-system clock used while Linux is running. The RTC can provide a starting point at boot; a network time client can then correct and discipline the system clock. Debian's timedatectl(1) documentation recommends keeping the RTC in UTC where possible because storing local time creates ambiguity around timezone changes and daylight-saving transitions.

Wall clock and monotonic clock

Applications also need to distinguish “what date and time is it?” from “how much time has elapsed?” Linux exposes CLOCK_REALTIME for wall-clock time and CLOCK_MONOTONIC for elapsed-time measurements. The Linux clock_gettime(2) manual explains that real time can experience discontinuous jumps, while the monotonic clock does not follow those wall-clock jumps. Time synchronization cannot repair an application that uses wall time carelessly for durations and timeouts.

Synchronization state

Synchronization is the ongoing relationship between the system clock and one or more reference sources. It is not the same as a service merely being enabled. A healthy audit asks whether a source has recently supplied acceptable measurements and whether the remaining uncertainty is suitable for the workload.

Inspect Before Changing Anything

Begin with commands that do not modify the clock:

date --iso-8601=seconds
timedatectl status
systemctl list-units --type=service | grep -E 'chrony|timesync|ntp'

The first command provides an unambiguous timestamp with its UTC offset. timedatectl status reports local time, UTC, RTC time, timezone, whether the system clock is synchronized, and whether a recognized network-time service is active. The service search helps identify the actual provider rather than assuming that every Debian installation uses the same one.

Read these fields separately. “NTP service: active” says that a known synchronization service is active; it does not by itself prove that a recent measurement was accepted. “System clock synchronized: yes” is stronger evidence, but it is still a summary produced by the local stack, not an external guarantee of accuracy.

If systemd-timesyncd is the provider, inspect its current measurement and recent log:

timedatectl timesync-status
systemctl status systemd-timesyncd.service
journalctl -u systemd-timesyncd.service --since today

The systemd-timesyncd(8) manual documents timesync-status for this purpose. Its output can include the selected server, poll interval, stratum, root distance, offset, delay, jitter, packet count, and frequency correction. One snapshot is useful; a sequence observed over time is more informative.

If chrony is installed, use its own interface instead:

chronyc tracking
chronyc sources -v

The official chronyc(1) manual describes tracking as a view of system-clock performance and sources -v as a view of source state. In the source list, * marks the selected best source, + another combined source, x a source considered inconsistent, and ? a source that is not currently selectable. The Reach field summarizes recent valid responses; it should be interpreted with the other fields, not treated as a standalone health score.

Choose a Client by the Evidence You Need

systemd-timesyncd is intentionally small. Its manual describes it as an SNTP-only client that steps large offsets and adjusts smaller ones gradually. For a simple host using a trusted, reliable source, that narrower role may be entirely sufficient. Its integration with timedatectl also makes a basic audit straightforward.

chrony covers a wider operational range. Its official FAQ and manuals document simultaneous use and selection of multiple sources, detailed offset and frequency reports, intermittent-network handling, NTP server operation, and optional Network Time Security (NTS). Those capabilities are useful when source disagreement, unstable connectivity, or stronger monitoring matters.

This is not a benchmark proving that one client is always better. Simplicity is a feature when the requirement is simple; richer source selection is a feature when the failure model needs it. The important rule is to identify one component responsible for disciplining the system clock. Do not enable a second client merely because the first status output was unfamiliar.

Source configuration also deserves restraint. timesyncd.conf(5) documents administrator drop-ins under /etc/systemd/timesyncd.conf.d/, which are preferable to editing vendor-owned files. chrony distinguishes server entries from pool entries and can select among multiple resolved sources. In either case, use sources whose operating policy is understood, respect public-pool rules, and avoid shortening poll intervals without a demonstrated reason.

Healthy Is More Than “Active”

No single field answers every timing question. A practical assessment combines several signals:

  • Service state: Is the intended client running, and is an unexpected competing client absent?
  • Recent source: Is a source selected, reachable, and providing accepted measurements?
  • Offset and uncertainty: Are the reported offset, delay, dispersion, or root-distance values plausible for this network and workload?
  • Trend: Does the client remain healthy across reboots, link interruptions, and ordinary periods of congestion?
  • Application requirement: Is the observed state good enough for what depends on it?

Stratum needs particular care. It describes a source's position in the NTP hierarchy. A lower number is not automatically proof of a better path from this client: network delay, source stability, uncertainty, and agreement with other sources still matter. Similarly, a tiny offset in one command output is a measurement at one moment, not a lifetime accuracy certificate.

Boot Order Can Expose a Correctness Gap

A server may boot with a poor RTC estimate and synchronize only after networking becomes available. This creates a window in which early services see an inaccurate wall clock. The systemd-timesyncd manual says that restoring its saved timestamp can make time advance roughly monotonically across reboots, including on systems without a battery-backed RTC. It also makes an important distinction: ordinary initialization does not hold every service until an accurate network source has been reached.

If an application truly cannot start safely before accurate synchronization, that is an explicit dependency to design and test, not something to infer from “NTP enabled.” systemd provides systemd-time-wait-sync.service and time-sync.target for this class of ordering, but whether to wait, time out, or run in a degraded mode is an application decision. Making the whole boot depend indefinitely on an unreachable public service can create a different failure.

Large corrections introduce another trade-off. Both systemd-timesyncd and chrony distinguish immediate steps from gradual slewing. The chrony manual warns that jumps can seriously affect some software. Controlled stepping near boot can be reasonable when little stateful work is running; forcing a jump on a busy server should not become a casual troubleshooting reflex.

NTP Security Has a Boundary

Basic network time should not be treated as authenticated merely because it arrived from a familiar hostname. An attacker on the path may attempt to forge, modify, delay, redirect, or drop unauthenticated exchanges. Multiple sources and sanity limits can reduce some risks, but they do not turn unauthenticated packets into cryptographic proof.

RFC 8915 defines NTS for NTP client-server mode. It uses TLS for key establishment and authenticated NTP extension fields for subsequent time exchanges. NTS can authenticate the server and packets, provide replay protection, and bind a response to a request. It still cannot prevent an on-path attacker from delaying or dropping packets, so authenticated time is stronger evidence, not magical certainty.

NTS also has a bootstrapping tension: TLS certificate validation itself depends on a sufficiently plausible local date. A working RTC or safely restored prior timestamp can help. Disabling certificate-time checks weakens the very assurance NTS is meant to provide and should not be presented as a routine fix.

A Short Failure Investigation

When synchronization is absent or stale, move through the path in order rather than changing several settings at once:

  1. Confirm the timezone, RTC interpretation, system-clock summary, and active time client.
  2. Inspect the provider-specific status and logs for the selected server, last accepted measurement, and explicit errors.
  3. Check whether source names resolve. A DNS failure can look like a time failure.
  4. Check routing and firewall policy. Traditional NTP exchanges normally use UDP port 123; NTS key establishment uses a separate TLS connection and requires compatible servers.
  5. Compare behavior over several polls instead of forcing an immediate clock change after one missing response.
  6. After recovery, verify the applications that consume time, not only the time daemon.

Intermittent connectivity changes the standard of success. A disconnected home server cannot continuously consult an Internet source, but a capable client can estimate oscillator drift and resume measurements when the link returns. That does not make the clock correct forever while offline. It makes the error more manageable and, importantly, observable.

Make Time an Explicit Dependency

A dependable server clock is not one impressive offset value. It is a documented chain: the RTC gives boot a plausible starting point, one known client disciplines the system clock, trusted sources remain reachable, status exposes uncertainty, and applications use wall or monotonic time according to what they are measuring.

The smallest useful maintenance habit is to record which client is responsible, inspect its provider-specific status after meaningful network or system changes, and define what “good enough” means for the services that depend on it. NTP can build a shared timeline, but it cannot decide how much uncertainty an application can tolerate. That last boundary remains a local engineering question.

References