timesyncd · Raspberry Pi 5

Raspberry Pi 5 won't keep the time: "NTP service: active" but "System clock synchronized: no"

Published 2026-10-16 · HardStacked · 10 min

Your Pi 5 shows the wrong date. Maybe frozen on some day months ago, maybe a few hours behind after every reboot. You type timedatectl and read NTP service: active, so you figure time sync is running. One line above it: System clock synchronized: no, and RTC time says 1970. You checked the network, the browser loads pages, so the forums send you to reinstall systemd-timesyncd or edit timesyncd.conf. Nobody tells you where the date you're looking at comes from.

Someone put the whole situation in a title on Raspberry Pi Stack Exchange (question 147143, 7,311 views, 2024-02-26, no accepted answer):

"Raspberry Pi 5 won't synchronize date and time"

The author's date was "stuck on 12/5/2023". A commenter called that IMPOSSIBLE. It isn't, and the reason is a file on your SD card.

01. The verdict

Measured on 2026-10-16 on a desk Pi 5 (Raspberry Pi 5 Model B Rev 1.1), Debian 13 trixie, systemd 257 (257.13-1~deb13u1), aarch64. Everything below comes from that machine, read-only, no sudo.

02. Light 1: "NTP service: active"

On a machine that did sync, here is what it looks like:

NTP service: active is on both sides of the story. The question's author had it too, next to System clock synchronized: no. Read the line above it. For proof that packets actually came back, timedatectl timesync-status has a Packet count:

48 packets answered on our machine. That counter is the number to look at, not the word "active".

03. Light 2: "Internet works, the browser too"

The question's author wrote that they could ping websites and use the browser. Their timesyncd journal, meanwhile, was full of Timed out waiting for reply from ...:123, in a loop.

Both are true at once. Your browser talks TCP on port 443. NTP talks UDP on port 123. Different protocol, different port, possibly a different path through your router, your firewall or your provider. A network that serves web pages says nothing about UDP 123 getting out and back.

We did not measure a network that blocks UDP 123, so we have no fix to hand you as tested. What the journal line tells you is the direction: requests leave, nothing comes back. Look at outbound firewall rules and at the router, not at timesyncd's config.

04. Light 3: the date isn't random

At boot, systemd refuses to start from a clock older than a floor it calls the epoch. If the clock is behind, it advances it to the epoch. According to man systemd (section SYSTEM CLOCK EPOCH) the epoch is the most recent of: systemd's build date, the mtime of /usr/lib/clock-epoch, and the mtime of /var/lib/systemd/timesync/clock. In its own words: "The epoch is set to the highest of: the build time of systemd, the modification time ("mtime") of /usr/lib/clock-epoch, and the modification time of /var/lib/systemd/timesync/clock"

That last file is the key. systemd-timesyncd rewrites it on a timer, and man timesyncd.conf (SaveIntervalSec=) says it is saved periodically "in the absence of any recent synchronisation" and is "especially useful for offline systems with no local RTC". Default interval is 60 s. In the source (v257), the save timer is armed before and independently of any network check. So it keeps saving the current system time even when no NTP answer ever comes.

Two cases follow.

A fresh card, never synced: the only saved time on it is the one written when the image was built. The question's author was stuck on 12/5/2023. The image is named 2023-12-05-raspios-bookworm-arm64.img.xz (checked on downloads.raspberrypi.com). Not impossible. Exactly what a saved clock predicts. One detail: that bookworm image ships fake-hwclock (it is in the image's package list), a second saver that restores a time kept in a file at boot. Our trixie machine doesn't have it, so on ours the timesyncd file is the only one at work. Which of the two set the 2023 date on the author's card, we can't tell from here; both point to the build date.

A machine that has run before: the epoch is the last time saved before the power cut. On our desk Pi 5, 10 of 11 cold boots restarted within 2 s of the moment the previous boot ended. At boot, the delay is the time spent unplugged.

Here is what it looks like on ours, last boot, three lines from the journal:

The machine had been off about 5 h 12 min. It restarted believing it was 11:08:30, the last saved time, and 36 s into the boot timesyncd corrected it by about 18,750 s. Because the network answers here, the error lasts 36 s. The question's author got no NTP answer, so they stayed on the starting date. That is where lights 2 and 3 meet: no reply on UDP 123, and a clock that starts from the last saved file.

What happens next without a network, we measured on a second Pi 5: no network, no battery, stored unplugged since mid-August, powered up on 2026-10-16 and read through a direct cable:

It believes it is 2026-08-15. A synced machine read at the same moment said 2026-10-16 21:28:05 UTC: 62 days, 4 h 56 min behind. Read twice, a minute and a half apart, the gap didn't move, and with System clock synchronized: no nothing on that machine will ever close it. That is the question, reproduced. Our notes from August show the same Pi 6 days behind once, then 1 h 31 behind after a later cold boot: without a network, the delay doesn't heal, it piles up.

05. Light 4: "RTC time: 1970"

The Pi 5 does have a hardware clock (connector J5, official documentation). Without a battery it restarts from zero when power is cut, not on a simple reboot. Look at the first line above: the kernel sets the system clock to 1970-01-01T00:00:09. The RTC started again from zero when power came back, and had counted nine seconds by the time the kernel read it.

Our check, across the journal (10-06 to 10-16): 15 boots logged. 11 cold starts with the RTC at 1970, so 11 times the "advanced to timestamp" line. 4 boots with the power left on, RTC correct, zero jump. For one of those, the kernel line reads setting system clock to 2026-10-09T17:54:39 UTC. The RTC had kept the time. 15 out of 15 consistent.

Now the battery. The official one is a rechargeable Li-Mn cell, and the doc says "Charging of the battery is disabled by default". Our board shows it:

charging_voltage:0. The official documentation (raspberrypi/documentation, computers/raspberry-pi/rtc.adoc) gives the switch: add dtparam=rtc_bbat_vchg=3000000 to /boot/firmware/config.txt, then reboot. We have no battery. We did not test this, we are only passing on the documentation. It also means a battery plugged in and never charged will run down and stop holding the time. How long that takes, we can't say. That is inferred.

06. Light 5: the journal lies too

If you read your logs after an incident, this one hurts. journalctl --list-boots (printed in UTC here):

Boot -1 ends at 15:08:31 and boot 0 starts at 15:08:32. One second apart. The machine was off about five hours between them, and the journal doesn't show it. Every cold boot starts stamped in the past, by hours or days, until the sync lands: 35 seconds to 8 minutes on our journal, depending on when the network answered. Boot 0 itself, per uptime -s, really started on 2026-10-15 at 16:20:59 EDT. Careful with time zones: --list-boots is in UTC, the systemd messages carry EDT (UTC minus 4) in their text. 15:08:32 UTC is 11:08:32 EDT, the same moment.

One more oddity, for the record. Look at boots -6 and -5: boot -5 starts at 00:32:41, while -6 ends at 00:35:01. A boot beginning 2 min 20 s before the previous one finished. We saw it, we did not measure its cause, so we won't guess.

07. The isolation method, three commands

These commands are provided as is, without warranty. Run them on a non critical machine first. All three are read-only.

First, timedatectl. Look at System clock synchronized, not at NTP service.

Second, journalctl -u systemd-timesyncd -b. If you read Timed out waiting for reply from ...:123, requests leave and nothing comes back: network, UDP 123. If you read Initial clock synchronization to ..., it works. The first text is from the Stack Exchange question, the second from our bench.

Third, the three lines per boot:

RTC at 1970 followed by "advanced to timestamp" on every boot means power cut with no battery.

Then pick your direction. Network: outbound firewall and router, UDP 123 (direction only, not measured). Clock: the battery and rtc_bbat_vchg from the official documentation.

Scope

Measured on Debian 13 trixie, systemd 257, Pi 5. Not measured: Raspberry Pi OS bookworm, chrony, a real battery, a network that blocks UDP 123.

The same shape runs through the rest of this series, where the system declares one thing and does another: an apt Signed-By: field that looks restricted and still accepts any key in trusted.gpg.d and a systemctl enable that reports failure while the service ends up enabled anyway.