Le service chrony ne change pas l'heure
L'idée souvent fausse est que le service chrony règle l'heure sur celle donnée par le serveur NTP. Ceci est incorrect - ce qui se passe réellement est que, sur la base de la réponse du serveur NTP, chrony indique simplement à l'horloge système d'accélérer ou de ralentir. Pour cette raison, parfois même si l'heure est erronée et que le serveur NTP fonctionne, l'heure n'est pas corrigée immédiatement.
Uniquement lorsque chrony règle l'heure
Lorsque le service chrony démarre, certains paramètres se trouvent dans le fichier /etc/chrony/chrony.conf fichier qui lui dit de régler l'heure si des conditions spécifiques se produisent :
# Force system clock correction at boot time. makestep 1000 10
ce qui signifie que si chrony détecte au cours des 10 premières mesures après son démarrage que l'heure est décalée de plus de 1000 secondes, il réglera l'horloge.
Quelques commandes utiles
Vous trouverez ci-dessous quelques commandes utiles qui peuvent être utilisées pour le dépannage des problèmes liés au chrony.
# chronyc tracking # chronyc sources # chronyc sourcestats # systemctl status chronyd # chronyc activity # timedatectl
Vérifier l'état de chronyd
Pour vérifier l'état du démon chronyd :
# systemctl status -l chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2016-08-12 13:22:22 IST; 1s ago
Process: 33263 ExecStartPost=/usr/libexec/chrony-helper update-daemon (code=exited, status=0/SUCCESS)
Process: 33259 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 33261 (chronyd)
CGroup: /system.slice/chronyd.service
└─33261 /usr/sbin/chronyd
Aug 12 13:22:22 NVMBD1S11BKPMED03 systemd[1]: Starting NTP client/server...
Aug 12 13:22:22 NVMBD1S11BKPMED03 chronyd[33261]: chronyd version 2.1.1 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP +DEBUG +ASYNCDNS +IPV6 +SECHASH)
Aug 12 13:22:22 NVMBD1S11BKPMED03 chronyd[33261]: Frequency 0.000 +/- 1000000.000 ppm read from /var/lib/chrony/drift
Aug 12 13:22:22 NVMBD1S11BKPMED03 systemd[1]: Started NTP client/server. La commande des sources chronyc
Exécuter des sources chronyc -v affiche l'état actuel du ou des serveurs NTP configurés dans le système. Voici un exemple de sortie, dans lequel ntp.example.com apparaît comme un serveur valide qui est en ligne :
# chronyc sources -v 210 Number of sources = 1 .-- Source mode '^' = server, '=' = peer, '#' = local clock. / .- Source state '*' = current synced, '+' = OK for sync, '?' = unreachable, | / 'x' = time may be in error, '~' = time is too variable. || .- xxxx [ yyyy ] +/- zzzz || / xxxx = adjusted offset, || Log2(Polling interval) -. | yyyy = measured offset, || | zzzz = estimated error. || | | MS Name/IP address Stratum Poll LastRx Last sample ============================================================================ ^* ntp.example.com 3 6 40 +31us[ -98us] +/- 118ms
Notez qu'un état source différent de "*" indique généralement un problème avec le serveur NTP.
L'état de la source "~" signifie que l'heure est trop variable
Si l'état de la source est "~ ', cela signifie probablement que le serveur est accessible mais que l'heure est trop variable. Cela peut arriver si le serveur répond trop lentement ou répond parfois plus lentement et parfois plus rapidement. Vous pouvez vérifier le temps de réponse des pings au serveur pour voir s'ils sont lents ou variables. Cet état a également été remarqué lorsque le serveur s'exécute sur des machines virtuelles trop lentes, ce qui entraîne des problèmes de synchronisation.
Chrony vérifie et redémarre toutes les heures
Une fois par heure, le service chrony vérifie la sortie des chronyc sources -v commande, en exécutant le script /usr/sbin/palladion_chrony_healthcheck qui exécute /usr/sbin/palladion_check_chrony et vérifie sa sortie :
- si /usr/sbin/palladion_check_chrony renvoie 1 - cela signifie qu'il n'y avait pas de source en ligne (pas de source avec Source state ='*') , donc chrony redémarre pour tenter de réinitialiser l'état du serveur
- si /usr/sbin/palladion_check_chrony renvoie 0 - cela signifie que tout va bien, chrony n'a pas besoin d'être redémarré car il a déjà une source en ligne valide
# cat /etc/cron.d/chrony SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin # # Check chrony every hour and restart if necessary. # 16 * * * * root /usr/sbin/palladion_chrony_healthcheck
Journaux Chrony
Il existe plusieurs journaux chrony qui peuvent être utilisés pour résoudre les problèmes. La plupart d'entre eux sont situés dans /var/log/chrony/ . Notez que le dernier fichier n'est pas toujours le fichier *.log. Il arrive parfois que même les fichiers *.log.2 ou *.log.3 soient les plus récents. Voici un exemple de liste des fichiers avec tri par le plus récent :
# ls -lisaht /var/log/chrony/ total 1.5M 3801115 580K -rw-r--r-- 1 root root 574K Oct 21 14:56 measurements.log.3 3801131 544K -rw-r--r-- 1 root root 540K Oct 21 14:56 statistics.log.3 3801166 356K -rw-r--r-- 1 root root 350K Oct 21 14:56 tracking.log.3 3801089 4.0K drwxr-xr-x 16 root root 4.0K Oct 21 00:01 .. 3801114 4.0K drwxr-xr-x 2 root root 4.0K Oct 21 00:01 . 3801128 0 -rw-r--r-- 1 root root 0 Oct 21 00:01 tracking.log 3801110 0 -rw-r--r-- 1 root root 0 Oct 21 00:01 measurements.log 3801120 0 -rw-r--r-- 1 root root 0 Oct 21 00:01 statistics.log 3801167 0 -rw-r--r-- 1 root root 0 Oct 20 00:01 tracking.log.1 3801165 0 -rw-r--r-- 1 root root 0 Oct 20 00:01 statistics.log.1 3801159 0 -rw-r--r-- 1 root root 0 Oct 20 00:01 measurements.log.1 ............
Essayez de configurer un seul serveur NTP en saisissant son adresse IP
Si jusqu'à présent vous avez utilisé deux serveurs NTP ou plus (soit parce qu'ils ont été définis, soit parce que vous avez entré un FQDN qui se résout dans différentes adresses IP), essayez de définir un seul serveur NTP en entrant une seule adresse IP. Cela peut résoudre votre problème lié au NTP.
Tracer la communication avec le serveur NTP
Pour vérifier si le serveur NTP répond ou non, il est possible de tracer le trafic entre chrony et le serveur NTP pendant un certain temps tout en surveillant le serveur :
1. Démarrez une trace pcap avec tcpdump sur le port NTP 123 et laissez-la s'exécuter jusqu'à ce que le problème apparaisse (exécutez-la dans 'screen' ou avec 'nohup' pour éviter qu'elle ne s'arrête si vous vous déconnectez de la commande shell)
2 . Dès que le problème réapparaît, obtenez un diagnostic système couvrant l'intégralité de l'historique puisque vous avez défini le serveur sur le nom DNS jusqu'à ce que l'écart se reproduise. Si cela produit un fichier trop volumineux, obtenez simplement les diagnostics du système pour les données actuelles et copiez en plus tous les fichiers de /var/log/chrony/ et tous les fichiers appelés /var/log/syslog* . N'oubliez pas d'arrêter la trace que vous avez commencée à l'étape 1