Chrony Et GPS: Résoudre 'not Valid Age' Après Un Reset

Salut les gars, on plonge dans le mystère du temps avec Chrony et le GPS!

Alors les potes, parlons d'un sujet super important mais souvent négligé jusqu'à ce que ça nous tombe dessus : la synchronisation horaire dans nos systèmes Linux. Imaginez un peu la catastrophe si vos logs sont désordonnés, si vos transactions sont mal datées ou si vos processus critiques ne s'exécutent pas au bon moment ! C'est là que Chrony entre en scène, ce petit bijou de logiciel qui gère la synchronisation de l'heure avec une précision redoutable. Contrairement à son cousin plus ancien, NTPd, Chrony est conçu pour des environnements plus dynamiques, avec des démarrages rapides, des connexions intermittentes et une meilleure gestion des variations de l'horloge système. C'est particulièrement vrai quand on parle de systèmes embarqués ou de serveurs qui ont besoin d'une fiabilité à toute épreuve, souvent en utilisant une source de temps externe comme le GPS.

Le GPS, ou Global Positioning System, n'est pas juste là pour vous guider en voiture, les amis. C'est aussi une source de temps absolument incroyable, capable de fournir une précision au niveau de la nanoseconde grâce aux horloges atomiques embarquées sur les satellites. Un module GPS peut fournir des impulsions par seconde (PPS) et des trames NMEA qui contiennent l'heure et la date. C'est précis, c'est fiable, et ça ne dépend pas d'une connexion internet. Ça a l'air parfait, non ? Eh bien, pas toujours ! Parfois, cette relation idyllique entre Chrony et le GPS peut tourner au vinaigre, surtout quand on rencontre l'erreur cryptique refclock not valid age. C'est le genre de message qui peut vous faire arracher les cheveux, surtout si votre système, après un reset complet, décide de vivre en 2024 au lieu de 2025. Oui, vous avez bien lu ! Un an d'avance, ou de retard, c'est selon. Cet écart, même d'une seule année, est catastrophique pour la synchronisation, et Chrony, dans sa grande sagesse, refuse catégoriquement d'utiliser une source qui lui semble "vieille" ou "incohérente". L'enjeu est de taille : pour les systèmes autonomes qui dépendent exclusivement d'une source GPS pour l'heure, un tel dysfonctionnement peut rendre le système totalement inopérant ou induire des erreurs irrécupérables. C'est une situation où la robustesse du système horaire est mise à rude épreuve, et où chaque détail de la configuration et du comportement du matériel compte. Nous allons décortiquer tout ça pour que vous puissiez remettre vos systèmes à l'heure, et pour de bon !

Comprendre l'erreur "refclock not valid age": Pourquoi Chrony nous embête?

"refclock not valid age". Ce petit message énigmatique, que l'on retrouve souvent dans les logs de Chrony (chronyc sources -v), est en fait une mesure de sécurité et de fiabilité mise en place par Chrony. Quand Chrony reçoit des données d'un refclock (une horloge de référence, comme votre module GPS), il ne les accepte pas aveuglément. Il effectue une série de vérifications pour s'assurer que les informations horaires sont fraîches, cohérentes et crédibles. L'"âge" fait référence à la validité temporelle des données. Si les données reçues sont considérées comme trop anciennes, ou si l'écart par rapport à l'heure système actuelle est aberrant, Chrony les rejette, jugeant que la source n'est pas fiable à cet instant précis. C'est un peu comme si Chrony disait : "Non, cette information est périmée ou complètement folle, je ne vais pas mettre mon système en danger avec ça !" Ce mécanisme est essentiel pour éviter des sauts de temps indésirables causés par des sources défectueuses ou instables.

Pourquoi cette erreur apparaît-elle si fréquemment avec les modules GPS? Plusieurs raisons peuvent expliquer cela, surtout lors d'un démarrage à froid de votre système ou du module GPS lui-même. Un module GPS a besoin de temps pour faire ce qu'on appelle un "fixe" ou "verrouillage" : il doit capter suffisamment de signaux satellites pour calculer sa position, et par extension, l'heure et la date précises. Pendant cette phase, avant d'obtenir un fixe valide (souvent un "3D fix" avec une bonne précision positionnelle et temporelle), le module peut envoyer des données NMEA qui contiennent une heure et une date par défaut, voire incorrectes, ou des drapeaux indiquant l'absence de fixe. Si Chrony interroge le module avant qu'il n'ait un fixe solide, il va recevoir ces données non fiables et générer l'erreur not valid age. L'un des scénarios les plus frustrants est celui où le système, après un reset complet, se retrouve avec une année incorrecte, comme 2024 au lieu de 2025. C'est un décalage énorme qui ne peut pas être géré facilement par les algorithmes de dérive habituels de Chrony. Cela indique clairement que le système reçoit une heure erronée dès le départ, bien avant que Chrony n'ait eu la chance de stabiliser quoi que ce soit. Chrony, en tant que gardien du temps, voit cet écart colossal et refuse de l'intégrer, d'où l'erreur persistante. Il attend désespérément une source de temps fiable et cohérente pour commencer son travail de haute précision.

Pour bien comprendre, il faut jeter un œil aux mécanismes internes de Chrony. Il ne se contente pas de prendre l'heure bêtement. Il calcule la dispersion des échantillons (la variabilité), l'offset (l'écart par rapport à l'horloge système), et la précision estimée. Si un échantillon de temps du refclock a une dispersion trop élevée, ou un offset gigantesque par rapport à ce que Chrony considère comme l'heure approximative (par exemple, l'heure de l'horloge matérielle ou du noyau), il sera rejeté. Le fichier driftfile, souvent /var/lib/chrony/drift ou /var/lib/chrony/chrony.drift, joue un rôle capital ici. Il contient la dernière dérive mesurée de l'horloge système. Lors d'un redémarrage, Chrony utilise cette information pour "deviner" une heure plus précise, en attendant les sources externes. Mais si le système démarre avec une heure aberrante (comme une année complètement fausse), cette dérive historique ne sert plus à rien, et Chrony se retrouve dans l'incapacité de corriger l'écart seul. C'est d'autant plus vrai si l'écart est trop grand pour être "glissé" (slew) progressivement, forçant Chrony à "sauter" (step) l'horloge, une opération qu'il préfère éviter car elle peut perturber certaines applications. C'est pourquoi des directives comme makestep et initstepslew sont cruciales pour gérer ces sauts de temps importants au démarrage, permettant à Chrony de réinitialiser l'horloge grossièrement avant de commencer la phase de réglage fin.

Le coupable : L'année 2024 au lieu de 2025 après un reset système

Alors, revenons-en à notre scénario cauchemardesque : votre système démarre après un reset complet, et hop, l'horloge est bloquée sur 2024 au lieu de l'actuelle 2025. C'est une erreur d'un an, ce qui est énorme pour Chrony et n'importe quel système qui se respecte. Mais d'où vient cette heure initiale incorrecte? C'est la question à un million de dollars, les amis. Il y a plusieurs suspects, et il est essentiel de les identifier pour résoudre le problème de manière durable et efficace.

Le premier coupable potentiel est la Real-Time Clock (RTC) de votre carte mère. La RTC est une petite horloge matérielle alimentée par une pile bouton (souvent une CR2032) qui maintient l'heure et la date même lorsque le système est éteint. Si cette pile est faible ou déchargée, la RTC peut perdre l'heure et se réinitialiser à une date par défaut arbitraire, qui pourrait bien être 2024 (ou une autre année incohérente) si c'était la valeur par défaut définie lors de la fabrication ou par le firmware du BIOS/UEFI. C'est souvent la première source d'heure pour le noyau Linux au démarrage, avant même que Chrony ne prenne la main ou que le module GPS n'ait eu le temps de faire son travail. Si la RTC est fausse, le noyau part du mauvais pied, et toutes les tentatives de synchronisation ultérieures seront compliquées par cet écart initial majeur. Il est donc impératif de vérifier la santé de votre pile RTC et de s'assurer que l'heure du BIOS/UEFI est correcte.

Ensuite, le firmware de votre module GPS lui-même peut être en cause. Certains modules GPS, en particulier lors d'un démarrage à froid (c'est-à-dire sans données d'éphémérides ou almanach préchargées), peuvent initialiser leur heure interne à une date par défaut avant d'obtenir un fixe GPS valide. Cette date peut être la date de fabrication du module, une date de l'époque Unix lointaine, ou même une date "temporaire" en attendant une fixation précise. Si votre système ne patiente pas suffisamment longtemps pour que le module GPS obtienne un fixe complet et stable (ce qui peut prendre plusieurs dizaines de secondes, voire quelques minutes dans de mauvaises conditions de réception), il pourrait récupérer cette date initiale erronée via les trames NMEA. C'est une course contre la montre au démarrage : qui va fournir l'heure en premier, et est-ce que cette heure sera la bonne ?

Un autre facteur crucial est l'ordre de démarrage des services. Si Chrony démarre avant que le module GPS n'ait eu le temps d'obtenir une fixe solide et de commencer à fournir des données valides, Chrony n'aura rien de crédible à se mettre sous la dent. Il verra des données GPS incorrectes ou absentes, d'où le not valid age. Pensez-y : si le système boote et l'horloge est à 2024, et que Chrony se met en marche et voit un GPS qui n'a pas encore de fixe (et donc potentiellement une date par défaut elle aussi erronée ou un indicateur d'invalidité), il est coincé. Il ne peut pas corriger une heure si l'unique référence qu'il a (le GPS) est elle-même en phase d'initialisation ou défaillante. C'est le problème majeur quand le GPS est la seule source de temps : il n'y a pas de filet de sécurité, pas d'autre source pour valider ou corriger l'heure initiale.

L'impact d'une seule source GPS est donc critique. Si cette unique source est initialement erronée ou lente à se stabiliser, Chrony n'a aucune autre référence pour valider ou corriger l'heure. Il ne peut pas "deviner" que l'année 2024 est fausse si le refclock lui-même la fournit. C'est pourquoi, même dans les systèmes les plus autonomes, envisager une source de temps secondaire pour le démarrage ou les situations d'urgence est souvent une sage décision. Pour diagnostiquer ces problèmes, l'analyse des logs Chrony (journalctl -u chrony ou cat /var/log/chrony/chrony.log si configuré) et des messages du noyau (dmesg) est fondamentale. Ces logs peuvent vous montrer précisément à quel moment l'heure déraille, si le GPS a du mal à se fixer, ou si Chrony rejette des échantillons. C'est votre meilleur ami pour comprendre la séquence des événements et identifier la source du problème, les amis.

Solutions et Astuces pour une Synchro GPS en Béton Armé

Maintenant que nous avons bien compris d'où vient le problème de cette année fantôme et de l'erreur refclock not valid age, il est temps de passer aux choses sérieuses : les solutions ! Il faut adopter une approche systématique pour s'assurer que votre synchronisation GPS soit en béton armé, même après un reset inopiné. Accrochez-vous, les potes, on va mettre les mains dans le cambouis !

Premièrement, il est crucial de vérifier le module GPS et sa sortie NMEA. Avant même de penser à Chrony, assurez-vous que votre module GPS fonctionne comme prévu. Vous pouvez utiliser des outils comme gpsmon, minicom, ou simplement cat /dev/ttyUSB0 (adaptez le port série selon votre configuration, souvent /dev/ttyACM0 pour les GPS U-blox ou /dev/ttyS0 pour les ports série intégrés) pour visualiser les trames NMEA brutes. Ces trames sont le langage de votre GPS. Cherchez en particulier les messages $GPRMC (Recommended Minimum Specific GPS/Transit Data) ou $GPGGA (Global Positioning System Fix Data). Ces messages contiennent des informations vitales, y compris l'heure, la date et l'état de la fixation GPS. Vérifiez si la date et l'heure qu'ils affichent sont correctes et valides avant que Chrony ne prenne la main. Est-ce que le module met du temps à obtenir un fixe après un "cold start" ? Certains modules nécessitent plus de temps pour capter les satellites et calculer une solution précise. Votre système doit absolument attendre un fixe 3D valide (qui indique une position et une heure fiables) avant de considérer l'heure GPS comme utilisable. Si le module ne fournit pas de données fiables rapidement, cela peut expliquer pourquoi Chrony le rejette.

Ensuite, il faut avoir une configuration Chrony optimisée pour gérer ces scénarios de démarrage difficiles. Voici quelques directives essentielles dans votre fichier /etc/chrony/chrony.conf:

• refclock SHM 0 ou refclock PPS /dev/pps0: Assurez-vous d'utiliser le bon driver de refclock et le bon périphérique. Pour la synchronisation PPS (Pulse Per Second), c'est souvent /dev/pps0 et c'est la source la plus précise. Le SHM 0 est souvent utilisé avec le démon gpsd qui expose l'heure GPS via la mémoire partagée. Vérifiez la documentation de votre module et de gpsd.
• maxdistance 16: Cette directive ajuste la distance maximale autorisée pour les échantillons de temps. Si les échantillons sont trop éloignés des autres, Chrony les rejette. Pour un démarrage avec une heure potentiellement très fausse, vous pourriez avoir besoin d'augmenter cette valeur temporairement, mais soyez prudent car cela peut aussi introduire des erreurs.
• makestep 1 3: C'est une directive fondamentale pour les problèmes de démarrage avec de grands écarts temporels. Elle permet à Chrony de faire un saut de temps immédiat si l'écart entre l'heure système et les sources de référence est supérieur à 1 seconde, pendant les 3 premières mises à jour après le démarrage. C'est crucial pour un système qui démarre avec une heure complètement fausse (comme notre 2024 au lieu de 2025). Sans makestep, Chrony essaierait de "glisser" (slew) l'horloge très lentement, ce qui prendrait des heures, voire des jours pour corriger un décalage d'un an !
• initstepslew 10 pool.ntp.org: Si votre système dispose d'une connexion réseau même intermittente au démarrage, c'est une stratégie hybride géniale pour éviter le problème initial. Cette directive indique à Chrony d'initialiser l'heure avec un serveur NTP standard (ici pool.ntp.org) si l'écart est supérieur à 10 secondes. Cela fournit une base de temps plus fiable au démarrage, avant même de compter sur la précision ultime du GPS. Une fois que Chrony a obtenu une heure à peu près correcte via NTP, il pourra ensuite affiner la synchronisation avec le GPS, qui prendra alors le rôle de source primaire et la plus précise. C'est un excellent filet de sécurité !
• rtcsync: Cette directive ordonne à Chrony de synchroniser l'horloge matérielle (RTC) avec l'horloge système. C'est extrêmement important pour les reboots. Si votre RTC est mise à jour avec l'heure correcte à chaque fois que Chrony fonctionne, elle aura une heure bien plus précise au prochain démarrage, réduisant ainsi les chances d'un décalage énorme au boot.
• log measurements statistics tracking: Activez un logging détaillé dans Chrony. Cela vous aidera énormément à diagnostiquer les problèmes. Vous pourrez voir les échantillons de temps reçus, les rejets, et l'état de la synchronisation. Consultez les logs avec chronyc tracking et chronyc sources -v.

La gestion de l'heure initiale du système est également primordiale. Assurez-vous que le BIOS/UEFI de votre carte mère a une date correcte. Changez la pile CMOS si elle est vieille. Il est possible d'avoir un script de démarrage qui s'exécute avant Chrony et qui attend une fixe GPS valide. Ce script pourrait analyser les trames NMEA jusqu'à ce qu'il voie une date et une heure cohérentes avec un fixe valide, puis utiliser `date -s