Synchronisation de l’horloge : vérifier les sources et les écarts chrony

Synchronisation de l’horloge : vérifier les sources et les écarts chrony

Des notifications de paiement jugées trop anciennes, des jetons de connexion qui deviennent parfois invalides ou des journaux dont l’ordre s’inverse entre processus peuvent avoir une même origine : une horloge système qui ne reste pas correctement synchronisée. Changer de fuseau horaire ne modifie que l’affichage, pas l’écart de l’horloge. Le diagnostic doit commencer par les sources de temps, l’état de synchronisation et les tolérances de l’application, plutôt que par une commande de remise à l’heure forcée.

Cet article prend chrony sous Debian 12 comme exemple pour suivre une démarche en quatre étapes : vérifier les sources, interpréter les écarts, mettre en place un contrôle bloquant et valider le rétablissement. Après le paiement d’un serveur dédié AmdMetal, les identifiants sont consultables dans la console pour se connecter en SSH ; si plusieurs adresses IPv4 sont disponibles, utilisez la première. Les opérations ci-dessous ne modifient pas les adresses réseau et ne nécessitent pas d’exposer de port d’administration.

1. Établir un état de référence : affichage et correction ne sont pas la même chose

Commencez par relever l’heure système, le fuseau horaire, la version du noyau et le service de synchronisation actif. Il est préférable d’uniformiser les journaux applicatifs avec un format de date et d’heure incluant le fuseau. Conservez également les heures en UTC dans les relevés de diagnostic pour ne pas confondre une différence d’affichage avec une dérive de l’horloge.

date --iso-8601=seconds
date -u --iso-8601=seconds
timedatectl status
uname -r
systemctl is-active chrony systemd-timesyncd

Les champs de synchronisation de timedatectl fournissent des indices, mais ne remplacent pas la vérification des sources de temps. Assurez-vous aussi qu’aucun autre processus de synchronisation ni aucune tâche de gestion de configuration ne règle l’horloge en parallèle. Les machines virtuelles hébergées doivent être contrôlées séparément : le bon état de l’hôte ne garantit pas celui des systèmes invités.

Si chrony n’est pas installé, vous pouvez l’installer depuis les dépôts du système. Toutefois, l’installation peut démarrer le service avec la configuration par défaut de la distribution. Sur une machine qui héberge déjà des applications, examinez d’abord la configuration qui sera appliquée et le comportement du paquet à l’installation, plutôt que d’installer puis d’observer les conséquences.

sudo apt-get update
sudo apt-get install chrony
systemctl status chrony --no-pager

Les bases de données, les services d’authentification et les ordonnanceurs de tâches en cours d’exécution peuvent être affectés par un saut de l’horloge civile. Tant que le comportement des applications n’a pas été évalué, n’exécutez ni date -s ni chronyc makestep, et ne tentez pas de « réparer l’heure » en redémarrant sans cesse le service de synchronisation.

2. Vérifier les sources de temps : une source joignable n’est pas forcément fiable

Après l’installation, examinez le fichier de configuration principal et les fichiers qu’il référence. Utilisez des adresses de sources approuvées par votre organisation. Ne recopiez pas des adresses publiques d’origine inconnue et ne considérez pas une source donnée comme une infrastructure fournie par ce site.

sudo grep -R -E \
'^[[:space:]]*(server|pool|peer|sourcedir|confdir|include|makestep|local|offline)' \
/etc/chrony
chronyc activity
chronyc sources -v
chronyc sourcestats -v

Les directives server et pool définissent les sources ; les répertoires inclus peuvent apporter des paramètres supplémentaires. Éliminez les doublons en tenant compte des serveurs réellement utilisés. Plusieurs noms peuvent aboutir à une même infrastructure : compter les lignes de configuration ne suffit donc pas à établir l’indépendance des sources.

Dans sources -v, * désigne la source de synchronisation actuellement sélectionnée, + une source participant à la combinaison, et ? une source qui ne peut pas être retenue pour le moment, par exemple parce qu’elle est injoignable ou que les échantillons sont insuffisants. Reach est un historique de joignabilité exprimé en octal : 377 indique qu’une réponse a été reçue lors de chacune des huit dernières interrogations, sans garantir l’exactitude de l’heure.

Dans quel ordre diagnostiquer une source défaillante

Vérifiez d’abord la résolution de noms, puis le routage vers l’adresse de la source et les règles de trafic sortant. Observez ensuite si les échantillons continuent à se renouveler. Recevoir une réponse NTP prouve seulement que la communication fonctionne ; une heure erronée à la source, des délais asymétriques ou des échantillons divergents peuvent toujours affecter la sélection. N’assouplissez pas le pare-feu de toute la machine dans le seul but de faire disparaître le symbole ?.

3. Interpréter les écarts sans se fier à un seul champ

chronyc tracking
journalctl -u chrony -b --no-pager -n 100

Le champ Reference time doit continuer à se mettre à jour. Si Leap status affiche Not synchronised, la validation doit échouer. System time correspond à la correction résiduelle estimée par chrony : une valeur proche de zéro ne constitue pas une preuve indépendante de l’erreur réelle par rapport à UTC.

Last offset et RMS offset renseignent sur les échantillons et les statistiques. Root delay et Root dispersion donnent des indications sur le chemin jusqu’à l’horloge de référence et sur l’incertitude associée. Ces champs doivent être interprétés avec l’état des sources, et non réduits à une valeur décimale isolée censée prouver que tout est conforme.

Il est conseillé de relever plusieurs séries de résultats couvrant plusieurs cycles d’interrogation. Distinguez la convergence après un démarrage à froid, la reconstitution des échantillons après le rétablissement du réseau et le fonctionnement en régime stable. Modifier continuellement la configuration pour réduire une valeur observée rend difficile l’identification du changement réellement efficace.

4. Mettre en place un contrôle de synchronisation à attente limitée

Pour les applications qui dépendent de l’heure, un contrôle avec une durée d’attente limitée peut être intégré au démarrage ou aux vérifications de déploiement. Les valeurs ci-dessous ne sont qu’un exemple technique. Les seuils réels doivent être définis en fonction de la durée de validité des jetons, des exigences d’audit et des tests applicatifs ; il ne s’agit pas d’un engagement de service.

chronyc waitsync 12 0.05 0 5

Cette commande effectue au maximum douze vérifications, espacées de cinq secondes. Elle exige que la synchronisation soit établie et que la correction résiduelle soit inférieure à 0.05 seconde. Le troisième paramètre, à zéro, n’impose aucune limite supplémentaire au skew. Une sortie réussie indique que ces conditions sont remplies, sans garantir que l’erreur réelle par rapport à UTC soit inférieure à cinquante millisecondes.

Les tâches automatisées doivent vérifier le code de sortie, et non masquer les messages d’échec :

if chronyc waitsync 12 0.05 0 5; then
    printf '%s\n' 'Clock gate passed'
else
    printf '%s\n' 'Clock gate failed' >&2
    exit 1
fi

L’échec du contrôle doit bloquer les étapes de démarrage concernées et avertir l’équipe d’exploitation, sans déclencher automatiquement une correction par saut d’horloge. network-online.target ne concerne que l’état de préparation du réseau et ne prouve pas non plus que l’horloge est synchronisée.

Tester le cas d’échec du contrôle

Dans un environnement de test isolé, vérifiez que le contrôle renvoie un code de sortie non nul lorsqu’aucune source n’est disponible, puis rétablissez les sources pour tester le cas de réussite. Ne modifiez pas l’heure globale d’un serveur dédié de production pour créer artificiellement un écart : cela affecterait tous les services et fausserait les journaux utilisés pour reconstituer la chronologie d’un incident.

5. Valider le rétablissement et conserver des éléments interprétables

Si des sources ont été déclarées hors ligne manuellement, n’exécutez chronyc online qu’après avoir confirmé le rétablissement du réseau. Si des échantillons supplémentaires sont nécessaires, vous pouvez lancer une fois chronyc burst 4/4 sur les sources configurées, puis réexaminer la sélection des sources et les résultats de tracking. Ne répétez pas cette commande en boucle, ce qui générerait des requêtes inutiles.

Lors de l’examen de makestep, soyez particulièrement attentif aux configurations telles que makestep 1.0 3 : elles autorisent une correction par saut pour les écarts dépassant le seuil lors des premières mises à jour de l’horloge après le démarrage. Un redémarrage du service peut réactiver cette phase ; « redémarrer pour voir » n’est donc pas sans risque. Si un saut important est réellement nécessaire, isolez d’abord les applications concernées et préparez entièrement le plan de rétablissement.

La validation finale doit couvrir les points suivants :

Pour mesurer des durées et gérer les délais d’expiration, privilégiez une horloge monotone ; réservez l’horloge civile aux horodatages applicatifs. En traitant séparément la façon dont l’application mesure le temps et la validation de la synchronisation de l’hôte, vous évitez qu’une remise à l’heure transforme une durée normale en valeur négative, tout en préservant des traces interprétables pour les incidents futurs.

Questions fréquentes

Un fuseau horaire correct prouve-t-il que l’horloge est synchronisée ?

Non. Le fuseau modifie seulement l’affichage. Vérifier la sélection dans chronyc sources -v, puis l’heure de référence, Leap status et les indicateurs d’erreur dans chronyc tracking.

Un succès de waitsync garantit-il moins de 50 ms d’écart avec UTC ?

Non. Le seuil 0.05 de l’exemple concerne la correction restante signalée par chrony, pas une mesure indépendante de l’erreur UTC. Vérifier aussi la fiabilité des sources, Root delay et Root dispersion.

Serveur dédié AMD EPYC 7543P

À partir de $458.7/mois

Configurer un serveur dédié AmdMetal Consulter les tarifs de location AmdMetal

Vérification détaillée de la configuration du serveur dédié

AMD EPYC 7543P dédié en exclusivité ; le modèle et les options sont calculés ensemble sur la page de configuration.