timesyncd · Raspberry Pi 5

Le Raspberry Pi 5 ne se met pas à l'heure : « NTP service: active » mais « System clock synchronized: no »

Publié le 2026-10-16 · HardStacked · 10 min

Ton Pi 5 affiche la mauvaise date. Peut-être figée sur un jour d'il y a des mois, peut-être en retard de quelques heures après chaque redémarrage. Tu tapes timedatectl et tu lis NTP service: active, donc tu penses que la synchro tourne. Une ligne plus haut : System clock synchronized: no, et RTC time affiche 1970. Tu as vérifié le réseau, le navigateur charge des pages, alors les forums t'envoient réinstaller systemd-timesyncd ou éditer timesyncd.conf. Personne ne t'explique d'où vient la date que tu regardes.

Quelqu'un a mis toute la situation dans un titre sur Raspberry Pi Stack Exchange (question 147143, 7 311 vues, 2024-02-26, aucune réponse acceptée) :

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

Traduction : « Le Raspberry Pi 5 ne synchronise pas la date et l'heure ».

La date de l'auteur était « stuck on 12/5/2023 ». Un commentaire a répondu que c'était IMPOSSIBLE. Ça ne l'est pas, et la raison tient dans un fichier sur ta carte SD.

01. Le verdict

Mesuré le 2026-10-16 sur un Pi 5 de bureau (Raspberry Pi 5 Model B Rev 1.1), Debian 13 trixie, systemd 257 (257.13-1~deb13u1), aarch64. Tout ce qui suit vient de cette machine, en lecture seule, sans sudo.

02. Voyant 1 : « NTP service: active »

Sur une machine qui s'est bien synchronisée, ça donne ça :

NTP service: active figure des deux côtés de l'histoire. L'auteur de la question l'avait aussi, à côté de System clock synchronized: no. Lis la ligne du dessus. Pour savoir si des paquets sont vraiment revenus, timedatectl timesync-status donne un Packet count :

48 paquets ont reçu une réponse sur notre machine. C'est ce compteur qu'il faut regarder, pas le mot « active ».

03. Voyant 2 : « Internet marche, le navigateur aussi »

L'auteur de la question dit pouvoir pinguer des sites et utiliser le navigateur. Son journal timesyncd, lui, est plein de Timed out waiting for reply from ...:123, en boucle.

Les deux sont vrais en même temps. Ton navigateur parle en TCP sur le port 443. NTP parle en UDP sur le port 123. Autre protocole, autre port, possiblement un autre chemin à travers ton routeur, ton pare-feu ou ton fournisseur. Un réseau qui sert des pages web ne dit rien sur l'UDP 123 qui sort et revient.

On n'a pas mesuré un réseau qui bloque l'UDP 123, donc on n'a aucun correctif à te donner comme testé. Ce que la ligne du journal t'indique, c'est la direction : les requêtes partent, rien ne revient. Regarde les règles de pare-feu sortant et le routeur, pas la config de timesyncd.

04. Voyant 3 : la date n'est pas aléatoire

Au démarrage, systemd refuse de partir d'une horloge plus vieille qu'un plancher qu'il appelle l'epoch. Si l'horloge est en retard, il l'avance à l'epoch. Selon man systemd (section SYSTEM CLOCK EPOCH), l'epoch est la plus récente de : la date de compilation de systemd, le mtime de /usr/lib/clock-epoch, et le mtime de /var/lib/systemd/timesync/clock. Dans ses propres mots : « 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 ».

Ce dernier fichier est la clé. systemd-timesyncd le réécrit à intervalle fixe, et man timesyncd.conf (SaveIntervalSec=) dit qu'il est sauvegardé périodiquement « in the absence of any recent synchronisation » et qu'il est « especially useful for offline systems with no local RTC ». L'intervalle par défaut est de 60 s. Dans le code source (v257), le minuteur de sauvegarde est armé avant, et indépendamment, de tout test de réseau. Il continue donc de sauvegarder l'heure système courante même quand aucune réponse NTP n'arrive jamais.

Deux cas en découlent.

Une carte neuve, jamais synchronisée : la seule heure sauvegardée dessus est celle écrite à la fabrication de l'image. L'auteur de la question était coincé au 12/5/2023. L'image s'appelle 2023-12-05-raspios-bookworm-arm64.img.xz (vérifié sur downloads.raspberrypi.com). Pas impossible. Exactement ce que prédit une horloge sauvegardée. Un détail : cette image bookworm contient fake-hwclock (il figure dans la liste des paquets de l'image), un deuxième mécanisme qui restaure au démarrage une heure gardée dans un fichier. Notre machine trixie ne l'a pas, donc chez nous le fichier de timesyncd travaille seul. Lequel des deux a posé la date de 2023 sur la carte de l'auteur, on ne peut pas le dire d'ici ; les deux mènent à la date de fabrication.

Une machine qui a déjà tourné : l'epoch est la dernière heure sauvegardée avant la coupure. Sur notre Pi 5 de bureau, 10 démarrages à froid sur 11 sont repartis à 2 s près de la fin du démarrage précédent. Au démarrage, le retard est le temps passé débranché.

Voici ce que ça donne chez nous, dernier démarrage, trois lignes du journal :

La machine était éteinte environ 5 h 12. Elle est repartie en croyant être à 11:08:30, la dernière heure sauvegardée, et 36 s après le début du démarrage timesyncd l'a corrigée d'environ 18 750 s. Comme le réseau répond ici, l'erreur dure 36 s. De son côté, l'auteur de la question n'a reçu aucune réponse NTP : sa machine est restée à l'heure de départ. C'est la jonction des voyants 2 et 3 : pas de réponse sur l'UDP 123, et une horloge qui repart du dernier fichier sauvegardé.

La suite sans réseau, on l'a mesurée sur un deuxième Pi 5 : pas de réseau, pas de pile, rangé débranché depuis la mi-août, rallumé le 2026-10-16 et lu par un câble direct :

Il se croit le 2026-08-15. Une machine synchronisée, lue au même instant, disait 2026-10-16 21:28:05 UTC : 62 jours et 4 h 56 de retard. Lu deux fois, à une minute et demie d'intervalle, l'écart n'a pas bougé, et avec System clock synchronized: no, rien sur cette machine ne le comblera jamais. C'est la question, reproduite. Nos notes d'août montrent le même Pi avec 6 jours de retard une fois, puis 1 h 31 après un démarrage à froid ultérieur : sans réseau, le retard ne guérit pas, il s'empile.

05. Voyant 4 : « RTC time: 1970 »

Le Pi 5 a bel et bien une horloge matérielle (connecteur J5, documentation officielle). Sans pile, elle repart de zéro quand l'alimentation est coupée, pas au simple redémarrage. Regarde la première ligne plus haut : le noyau règle l'horloge système à 1970-01-01T00:00:09. La RTC est repartie de zéro au retour du courant, et avait compté neuf secondes quand le noyau l'a lue.

Notre relevé, sur le journal (10-06 au 10-16) : 15 démarrages journalisés. 11 démarrages à froid avec la RTC à 1970, donc 11 fois la ligne « advanced to timestamp ». 4 démarrages avec l'alimentation maintenue, RTC juste, zéro saut. Pour l'un d'eux, la ligne du noyau dit setting system clock to 2026-10-09T17:54:39 UTC. La RTC avait gardé l'heure. 15 sur 15 cohérents.

Maintenant la pile. La pile officielle est une Li-Mn rechargeable, et la doc dit « Charging of the battery is disabled by default ». Notre carte le montre :

charging_voltage:0. La documentation officielle (raspberrypi/documentation, computers/raspberry-pi/rtc.adoc) donne l'interrupteur : ajouter dtparam=rtc_bbat_vchg=3000000 dans /boot/firmware/config.txt, puis redémarrer. On n'a pas de pile. On ne l'a pas testé, on relaie la documentation. Ça veut aussi dire qu'une pile branchée et jamais rechargée finira par se vider et ne plus tenir l'heure. Au bout de combien de temps, on ne peut pas le dire. Ça, c'est inféré.

06. Voyant 5 : le journal ment aussi

Si tu relis tes journaux après un incident, celui-là fait mal. journalctl --list-boots (imprimé en UTC ici) :

Le démarrage -1 finit à 15:08:31 et le 0 commence à 15:08:32. Une seconde d'écart. La machine est restée éteinte environ cinq heures entre les deux, et le journal ne le montre pas. Chaque démarrage à froid commence horodaté dans le passé, de plusieurs heures ou jours, jusqu'à ce que la synchro tombe : de 35 secondes à 8 minutes dans notre journal, selon le moment où le réseau a répondu. Le démarrage 0 a réellement commencé, selon uptime -s, le 2026-10-15 à 16:20:59 EDT. Attention aux fuseaux : --list-boots est en UTC, les messages de systemd portent EDT (UTC moins 4) dans leur texte. 15:08:32 UTC, c'est 11:08:32 EDT, le même instant.

Une bizarrerie de plus, pour mémoire. Regarde les démarrages -6 et -5 : le -5 commence à 00:32:41 alors que le -6 finit à 00:35:01. Un démarrage qui commence 2 min 20 s avant la fin du précédent. On l'a constaté, on n'en a pas mesuré la cause, donc on ne la devine pas.

07. La méthode d'isolement, trois commandes

Ces commandes sont fournies telles quelles, sans garantie. Teste d'abord sur une machine non critique. Les trois sont en lecture seule.

D'abord timedatectl. Regarde System clock synchronized, pas NTP service.

Ensuite journalctl -u systemd-timesyncd -b. Si tu lis Timed out waiting for reply from ...:123, les requêtes partent et rien ne revient : réseau, UDP 123. Si tu lis Initial clock synchronization to ..., ça marche. Le premier texte vient de la question Stack Exchange, le second de notre banc.

Enfin les trois lignes par démarrage :

RTC à 1970 suivie de « advanced to timestamp » à chaque démarrage, c'est une alimentation coupée sans pile.

Ensuite tu choisis ta direction. Réseau : pare-feu sortant et routeur, UDP 123 (direction seulement, non mesuré). Horloge : la pile et rtc_bbat_vchg de la documentation officielle.

Portée

Mesuré sur Debian 13 trixie, systemd 257, Pi 5. Non mesuré : Raspberry Pi OS bookworm, chrony, une vraie pile, un réseau qui bloque l'UDP 123.

La même forme traverse le reste de cette série, où le système déclare une chose et en fait une autre : un champ Signed-By: d'apt qui a l'air restreint et accepte quand même n'importe quelle clé de trusted.gpg.d et un systemctl enable qui annonce un échec alors que le service finit activé quand même.