Question
systemd-timesyncd FallbackNTP and Hardware Clock Synchronization
Ari Finch
0 reputation · 27 Sept 2024, 03:35 UTC
31K views1
Loading…
0 reputation · 27 Sept 2024, 03:35 UTC
In openSUSE, systemd-timesyncd manages network time synchronization by reading primary NTP servers from /etc/systemd/timesyncd.conf. While the service handles system clock updates, there is a distinction between updating the system time and the hardware clock (RTC), especially when the hardware clock is configured to use local time instead of UTC.
When the hardware clock is set to local time via hwclock --systohc --localtime, the synchronization process may result in an inconsistent state because systemd-timesyncd primarily targets the system clock. This creates uncertainty regarding how the RTC is maintained during fallback events when the primary NTP server is unreachable and the service switches to the FallbackNTP pool.
Given a systemd version 249 or newer, the following behaviors require clarification:
systemd-timesyncd trigger a hardware clock update specifically after a successful fallback synchronization?SyncInterval setting impact the latency of the fallback transition when the primary server returns an error versus being completely unreachable?34775 reputation · 27 Sept 2024, 08:25 UTC
No. systemd-timesyncd does not update the hardware clock (RTC) after a successful synchronization, whether the time came from a primary NTP server or the FallbackNTP pool. It only adjusts the system clock (CLOCK_REALTIME).
There is no SyncInterval setting in timesyncd.conf. Polling cadence is controlled by PollIntervalMinSec and PollIntervalMaxSec. An unreachable primary server forces a timeout before the client tries FallbackNTP; a server returning a protocol error may be rejected sooner, but the exact transition time is internal to systemd and version-sensitive.
opensusesystemd-timesyncd is a lightweight SNTP client; it writes to the system clock, not /dev/rtc, and does not invoke hwclock.timedatectl set-local-rtc true, that automatic path is unreliable, so the RTC can drift away from the corrected system time.PollIntervalMinSec and PollIntervalMaxSec set how often timesyncd polls; they do not document a fixed primary-to-fallback failover time.After fallback synchronization succeeds, the system clock is corrected, but the RTC keeps its previous value until the next kernel update or until you run hwclock --systohc --localtime manually. If your RTC uses local time, that manual step is necessary because the kernel's automatic UTC assumption does not apply.
systemctl cat systemd-timesyncd
grep -E '^(NTP|FallbackNTP|PollIntervalMinSec|PollIntervalMaxSec)' /etc/systemd/timesyncd.conftimedatectl
hwclock --debug --readtimedatectl set-local-rtc falsehwclock --systohc --localtime/etc/systemd/timesyncd.conf, adjust PollIntervalMinSec and PollIntervalMaxSec, then restart:systemctl restart systemd-timesyncdRestart systemd-timesyncd with NTP reachable, then compare date and hwclock --read before and after. If they diverge, timesyncd is not updating the RTC, which is expected. Watch journalctl -u systemd-timesyncd during a primary-server outage to confirm the service falls back to FallbackNTP.
One missing detail changes the recommendation: do you dual-boot with Windows or another OS that expects the RTC to keep local time? If yes, keep local-time RTC and run hwclock --systohc --localtime manually; if no, switch the RTC to UTC and let the kernel maintain it automatically.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 27 Sept 2024, 13:10 UTC
systemd-timesyncd updates only the system clock; it never invokes hwclock --systohc or similar after a successful fallback synchronization. The hardware clock (RTC) is kept in sync by systemd-timedated (or the timedatectl command) which copies the system time to the RTC on shutdown, on startup if the RTC is marked as UTC, or when timedatectl set-rtc is used explicitly. Consequently, after a fallback to FallbackNTP the RTC will remain unchanged until one of those events occurs.
Regarding SyncInterval, the service polls at that interval when a server is reachable. If a primary NTP server returns an error (\"timeout\" or \"unsupported mode\"), timesyncd treats it as a failure and may wait the full SyncInterval before retrying. If the server is completely unreachable (no response), the failure is detected faster, triggering an immediate fallback to the next server or to the FallbackNTP pool after a short back‑off (typically a few seconds). Thus, latency to switch to FallbackNTP is lower for total loss of connectivity than for intermittent error responses.