Une coupure de courant, le serveur redémarre, et le journal affiche soudain une date d’il y a deux ans. On pense tout de suite à une pile CMOS morte ou à une carte mère fatiguée. C’est rarement le cas. Ce qui se passe est plus banal : une horloge dérive en permanence, et rien ne vient la rattraper au redémarrage. Comprendre ce mécanisme évite de changer du matériel pour rien, et explique aussi pourquoi le problème revient après chaque extinction.
Le noyau ne connaît pas l’heure, il compte des battements
Un système d’exploitation n’a aucune notion innée de la date. Il mesure un intervalle à partir d’un compteur matériel, et ce compteur avance légèrement trop vite ou trop lentement selon la température, la charge et la qualité du quartz.
Sur un serveur classique, l’écart reste faible, quelques secondes par jour tout au plus, mais il ne disparaît jamais. Au démarrage, la machine lit une valeur approximative dans sa puce d’horloge temps réel, puis la laisse filer seule.
Voilà pourquoi une coupure ne fait pas « dérailler » l’horloge : elle supprime simplement la correction qui la maintenait dans le droit chemin. Tant que la machine tournait avec un service de synchronisation actif, l’écart restait invisible. À l’arrêt, plus personne ne corrige. La dérive reprend donc de plus belle, et la date inscrite dans le journal au redémarrage suivant peut surprendre.
En virtualisation, l’horloge de l’invité subit une seconde dérive
Sur une machine virtuelle, le problème se corse. L’invité partage un processeur physique avec d’autres invités, et quand l’hyperviseur ne le planifie pas, il ne peut tout simplement pas mesurer le temps écoulé. Les ticks manqués s’accumulent.
Sur un invité KVM récent, la source paravirtualisée kvm-clock corrige en grande partie ce biais : elle lit une valeur maintenue par l’hôte, si bien qu’un invité en bonne santé reste étroitement synchronisé avec sa machine physique. Encore faut-il que cette source soit active et que rien ne vienne la parasiter.
C’est là que beaucoup d’administrateurs se trompent de cible. Ils soupçonnent le disque, la RAM, l’alimentation, alors que le décalage vient d’une horloge jamais recadrée. Un invité synchronise son horloge avec son hôte ou avec un serveur NTP. Il ne la synchronise jamais avec son propre oscillateur, qui n’est de toute façon pas fiable.
Les vraies causes d’une horloge fausse
Quand une horloge part franchement de travers, la cause est presque toujours l’une des situations suivantes : un service de synchronisation absent, deux démons qui se marchent dessus, un filtrage réseau qui bloque les échanges, ou un hôte virtuel qui dérive lui-même. Aucun test matériel ne détecte ces cas de figure. C’est précisément pour cette raison qu’on tourne en rond pendant des heures avant de comprendre où se situe le vrai problème. Sur ce point, voir aussi notre article sur sauvegarde wordpress angles morts.
Ce qu’il faut vérifier avant de toucher au matériel
- Un daemon de synchronisation ne tourne pas du tout, souvent parce qu’il a été désactivé après une mise à jour.
- Deux daemons se disputent l’horloge en même temps, et leurs corrections s’annulent l’une l’autre.
- Les paquets UDP sortants vers le port 123 n’atteignent jamais le serveur distant.
- Les paquets vers le port 123 sont filtrés par le pare-feu du fournisseur, et le serveur parle alors dans le vide.
- L’horloge de l’hôte virtuel dérive elle-même, ce qui contamine tous les invités qui s’y appuient.
- La source de temps configurée pointe vers un serveur interne lui-même jamais recalé.
Le second cas est le plus vicieux. Chrony et systemd-timesyncd qui cohabitent sur la même machine produisent un ballet invisible : chacun croit corriger l’autre, et la date oscille sans jamais se stabiliser. Vérifier qui tient l’horloge prend deux minutes. Cela règle parfois un problème qui traînait depuis des mois.
Les seuils qui rendent une dérive critique
Toutes les dérives ne se valent pas. Certaines applications tolèrent une minute d’écart sans broncher, d’autres cassent au bout d’une seconde. La frontière de validité d’un certificat TLS, fixée par la RFC 5280, vaut zéro seconde : un certificat présenté avec une seconde d’avance sur l’horloge du vérificateur est rejeté.
La documentation de chrony sous Debian et Ubuntu prévoit un basculement en mode « steps instead of slewing » dès une seconde d’écart, parce qu’au-delà, corriger progressivement prendrait trop de temps. Pour un code TOTP, trente secondes de décalage suffisent à faire échouer l’authentification à deux facteurs, un pas de temps étant défini par la RFC 6238. Kerberos, lui, refuse l’authentification au-delà de trois cents secondes de décalage, une valeur par défaut de MIT krb5.
Un serveur dont l’horloge a dérivé de plusieurs heures après une coupure n’est donc pas juste « un peu en retard ». Il est inutilisable pour tout ce qui touche à l’authentification, aux certificats ou aux jetons temporaires. Les messages d’erreur, eux, ne pointent presque jamais vers l’heure.
Rien de tout ça ne relève du matériel. Une pile CMOS usée provoque une perte d’heure au démarrage, certes, mais elle se repère facilement : l’horloge repart d’une date figée, identique à chaque extinction, souvent calée sur une valeur d’usine. Une dérive ordinaire, elle, produit un décalage variable, qui grandit avec le temps de fonctionnement. La distinction est utile. Elle évite un remplacement inutile quand la vraie solution tient dans un fichier de configuration.
Parmi les ressources qui détaillent le fonctionnement des sources de temps et des protocoles de synchronisation, media-edge.com rassemble des explications techniques sur l’infrastructure réseau et les services d’horodatage. Ça complète bien ce qu’on voit côté système quand un daemon refuse de démarrer, ou quand un pare-feu avale silencieusement les requêtes NTP.
Le balancier s’arrête, et alors ?
La question revient parfois pour les horloges anciennes, celles qu’on garde dans un coin du bureau ou dans un atelier. Si le balancier s’arrête, rien de grave : l’horloge perd simplement la mesure du temps écoulé, exactement comme un serveur éteint. Il suffit de la remettre en marche et de la recaler sur une référence fiable, une horloge radio-pilotée ou une application de précision sur téléphone. Aucun composant n’est en cause.
Le mécanisme reste le même à toutes les échelles. Une horloge qui n’est jamais recalée finit par mentir, et l’arrêt ne fait qu’exposer un écart qui existait déjà. La bonne réaction après une coupure n’est pas de chercher une panne. Il faut vérifier qu’un service de synchronisation tourne, seul, et que ses paquets sortent vraiment. Combien de temps votre serveur pourrait-il tourner avant que sa date devienne un problème ?
