Vérifier la synchronisation de l’heure NTP sur un serveur Linux

Une horloge Linux mal synchronisée peut compliquer la lecture des journaux, invalider une vérification de certificat SSL ou produire des écarts entre plusieurs serveurs. Sur un VPS, un serveur dédié ou une machine virtuelle, le premier réflexe n’est pas de modifier la date manuellement : il faut d’abord observer l’état de la synchronisation NTP, le service de temps utilisé et la source NTP sélectionnée.

Le contrôle rapide avec timedatectl

Sur une distribution qui utilise systemd, commencez par afficher l’état général de l’horloge :

timedatectl status

Recherchez les lignes relatives à l’heure locale, à l’heure universelle UTC, au fuseau horaire, à l’horloge matérielle et à la synchronisation réseau. Une horloge configurée sur UTC n’est pas une erreur : c’est un choix courant sur les serveurs. Il faut distinguer le fuseau affiché de l’état réel de synchronisation.

Vous pouvez obtenir les indicateurs principaux avec :

timedatectl show -p Timezone -p NTPSynchronized -p NTP --value

Une valeur indiquant que NTP est activé ne prouve pas à elle seule qu’un ajustement récent a réussi. Complétez ce contrôle par l’état du service, la source de temps, le décalage mesuré et les journaux.

Identifier le service qui synchronise l’horloge

Selon l’installation, la synchronisation peut être assurée par systemd-timesyncd, chrony ou un autre démon compatible avec le protocole NTP. Un serveur NTP fournit l’heure à un client NTP ; le client compare les réponses, mesure le délai réseau et ajuste progressivement l’horloge locale. Commencez par repérer les unités liées au temps :

systemctl list-units --type=service --all | grep -Ei 'time|chrony|ntp'

Pour systemd-timesyncd, consultez l’état de l’unité et ses messages :

systemctl status systemd-timesyncd --no-pager
journalctl -u systemd-timesyncd --since today --no-pager

Pour chrony, l’état du service se vérifie de la même manière, puis ses commandes permettent d’observer les sources et l’état de l’horloge :

systemctl status chrony --no-pager
chronyc tracking
chronyc sources -v

Ne lancez pas plusieurs services de synchronisation concurrents sans savoir lequel est prévu par la distribution. Deux démons peuvent tenter de piloter la même horloge et rendre le diagnostic ambigu. Le nom exact de l’unité varie selon la distribution : vérifiez l’unité réellement présente avant toute action.

Lire les sources NTP, le stratum et l’offset

Une source NTP peut être joignable sans que l’horloge soit considérée comme synchronisée. Dans la sortie de chrony, examinez la source sélectionnée, le stratum, le délai, l’offset, la dispersion et la stabilité de la mesure. Le stratum décrit la distance logique par rapport à une référence de temps ; l’offset correspond à l’écart estimé entre l’horloge locale et la source. Une source marquée comme sélectionnée est plus informative qu’une simple liste de serveurs configurés.

La commande de suivi donne également des indices sur la référence, la précision, la fréquence de l’horloge et la dérive. La dérive, parfois appelée drift, décrit la tendance de l’horloge locale à avancer ou à retarder. Ne comparez pas seulement l’heure affichée : un faible écart instantané ne garantit pas une synchronisation durable si la source, le délai ou la stabilité sont mauvais.

Avec systemd-timesyncd, affichez les serveurs et l’état de synchronisation :

timedatectl timesync-status

Si aucune source n’est sélectionnée, vérifiez d’abord la connectivité réseau et la résolution DNS. Le protocole NTP utilise généralement le port UDP 123 : un pare-feu, une règle réseau ou une politique du fournisseur peut empêcher les échanges. Une résolution DNS réussie ne prouve pas que le trafic UDP vers la source est autorisé.

Vérifier les journaux et l’heure affichée

Les journaux permettent de repérer une erreur d’accès à la source, une impossibilité de résolution, un délai d’attente, une réponse rejetée ou un changement d’état du service. Filtrez la période observée plutôt que de lire tout le journal :

journalctl --since "1 hour ago" --no-pager | grep -Ei 'ntp|timesync|chrony|clock|synchron'

Si la commande ne renvoie rien, cela ne signifie pas automatiquement que NTP est arrêté. Le service peut écrire dans un journal différent, utiliser un niveau de détail limité ou ne pas avoir rencontré d’événement récent. Comparez alors l’état systemd, la sortie du client NTP et l’heure UTC :

date -u
systemctl is-active systemd-timesyncd
systemctl is-active chrony

Conservez les sorties avant de redémarrer un service : elles donnent un état de référence utile pour comparer le résultat après correction.

Les causes fréquentes d’un décalage

• Service absent ou inactif : aucun démon ne corrige l’horloge, ou l’unité attendue n’est pas celle installée.
• Source inaccessible : le serveur ne peut pas joindre la source NTP à cause du réseau ou d’un filtrage UDP 123.
• Résolution DNS défaillante : le nom de la source ne peut pas être résolu, ce qui doit être vérifié séparément.
• Horloge très éloignée : une correction importante peut nécessiter un traitement particulier du service de temps.
• Conflit de services : plusieurs démons tentent de piloter la même horloge.
• Confusion de fuseau : l’heure UTC est correcte, mais l’heure locale semble différente à cause du fuseau configuré.
• Dérive persistante : l’offset réapparaît après une correction car l’horloge avance ou retarde régulièrement.

Évitez de régler manuellement l’heure comme solution durable. Une modification ponctuelle peut masquer la cause et créer un saut temporel difficile à corréler avec les journaux, les tâches cron, les certificats et les connexions d’un service distant.

Prendre en compte l’environnement d’hébergement

Sur Debian ou Ubuntu, les commandes systemd sont courantes ; sur Rocky Linux ou Fedora, le service et le paquet peuvent porter un nom différent. Dans tous les cas, documentez la distribution, l’adresse IP du serveur, le nom d’hôte, le fuseau et la configuration du pare-feu avant de modifier un réglage. Cette fiche est utile pour un VPS administré en SSH comme pour un serveur dédié hébergeant une application web.

Le diagnostic NTP ne remplace pas les contrôles applicatifs. Un serveur web, une base de données, un proxy ou une tâche de sauvegarde peut avoir son propre journal et son propre délai d’expiration. Après rétablissement de l’heure, vérifiez les certificats SSL, les connexions distantes et la configuration du serveur qui dépendait de l’horodatage.

Procédure de diagnostic reproductible

1. Noter timedatectl status, date -u et le fuseau configuré.
2. Identifier le client NTP actif avec systemctl, sans supposer son nom.
3. Lire son état et ses journaux sur une période courte.
4. Observer les sources avec l’outil correspondant, comme chronyc tracking ou timedatectl timesync-status.
5. Contrôler stratum, offset, délai, dispersion et source sélectionnée lorsque ces informations sont disponibles.
6. Vérifier séparément DNS, réseau et filtrage UDP 123 si une source reste inaccessible.
7. Après une correction autorisée, répéter exactement les mêmes commandes et comparer les résultats.

Cette méthode évite de confondre un problème de temps avec un problème de fuseau, de DNS ou de réseau. Elle est également plus facile à transmettre au support lorsqu’un VPS reste désynchronisé.

Contrôles après synchronisation

Une fois l’état synchronisé confirmé, vérifiez les services qui dépendaient de l’heure : certificats, tâches cron, journaux d’un serveur de jeu, authentification et échanges entre plusieurs serveurs. Une horloge corrigée ne répare pas rétroactivement un certificat déjà expiré ni un événement enregistré avec une mauvaise heure, mais elle stabilise les prochains événements.

Pour préparer un environnement serveur cohérent, consultez notre guide sur l’analyse des journaux Linux avec journalctl, ainsi que celui consacré à la résolution DNS sur Linux. Les contrôles réseau complémentaires sont détaillés dans le guide pour lister les ports en écoute avec ss et dans celui sur le diagnostic rapide d’un VPS inaccessible.