Der Chrony-Dienst ändert die Zeit nicht
Das häufige Missverständnis ist, dass der Chrony-Dienst die Zeit auf die vom NTP-Server angegebene Zeit setzt. Das ist falsch – was tatsächlich passiert, ist, dass chrony basierend auf der Antwort des NTP-Servers der Systemuhr einfach mitteilt, schneller oder langsamer zu gehen. Aus diesem Grund wird die Uhrzeit manchmal nicht sofort korrigiert, obwohl die Uhrzeit falsch ist und der NTP-Server funktioniert.
Nur Zeit, wenn Chrony Zeit setzt
Wenn der Chrony-Dienst startet, gibt es einige Einstellungen in der /etc/chrony/chrony.conf Datei, die es anweist, die Zeit tatsächlich einzustellen, wenn bestimmte Bedingungen eintreten:
# Force system clock correction at boot time. makestep 1000 10
Das heißt, wenn chrony während der ersten 10 Messungen nach seinem Start feststellt, dass die Zeit um mehr als 1000 Sekunden abweicht, stellt es die Uhr ein.
Einige nützliche Befehle
Nachfolgend finden Sie einige nützliche Befehle, die zur Fehlerbehebung bei chronischen Problemen verwendet werden können.
# chronyc tracking # chronyc sources # chronyc sourcestats # systemctl status chronyd # chronyc activity # timedatectl
Chronyd-Status prüfen
So überprüfen Sie den Status des chronyd-Daemons:
# 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. Der Befehl chronyc sources
Ausführen von chronyc sources -v zeigt den aktuellen Zustand des/der im System konfigurierten NTP-Server an. Hier ist eine Beispielausgabe, in der ntp.example.com als gültiger Server angezeigt wird, der online ist:
# 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
Beachten Sie, dass ein anderer Quellstatus als „*“ normalerweise auf ein Problem mit dem NTP-Server hinweist.
Quellstatus ‚~‘ bedeutet, dass die Zeit zu variabel ist
Wenn der Quellzustand „~ ist ‘, bedeutet dies wahrscheinlich, dass der Server erreichbar ist, aber die Zeit zu variabel ist. Dies kann passieren, wenn der Server zu langsam reagiert oder mal langsamer und mal schneller reagiert. Sie können die Antwortzeit der Pings an den Server überprüfen, um festzustellen, ob sie langsam oder variabel sind. Dieser Zustand wurde auch festgestellt, wenn der Server auf virtuellen Maschinen läuft, die zu langsam sind und Zeitprobleme verursachen.
Chrony prüfen und stündlich neu starten
Einmal pro Stunde überprüft der Chrony-Dienst die Ausgabe von chronyc sources -v Befehl, indem Sie das Skript /usr/sbin/palladion_chrony_healthcheck ausführen welches /usr/sbin/palladion_check_chrony ausführt und überprüft seine Ausgabe:
- Wenn /usr/sbin/palladion_check_chrony 1 zurückgibt, bedeutet dies, dass keine Online-Quelle vorhanden war (keine Quelle mit Quellstatus =„*“), sodass Chrony neu gestartet wird, um zu versuchen, den Serverstatus neu zu initialisieren
- Wenn /usr/sbin/palladion_check_chrony 0 zurückgibt – bedeutet dies, dass alles in Ordnung ist, chrony muss nicht neu gestartet werden, da es bereits eine gültige Online-Quelle hat
# 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
Chrony-Protokolle
Es gibt mehrere Chrony-Protokolle, die zur Fehlerbehebung verwendet werden können. Die meisten von ihnen befinden sich in /var/log/chrony/ . Beachten Sie, dass die neueste Datei nicht immer die *.log-Datei ist. Manchmal kommt es vor, dass sogar die *.log.2- oder *.log.3-Datei die neueren sind. Hier ist ein Beispiel für das Auflisten der Dateien mit Sortierung nach den neuesten:
# 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 ............
Versuchen Sie, nur einen NTP-Server einzustellen, indem Sie dessen IP-Adresse eingeben
Wenn Sie bisher zwei oder mehr NTP-Server verwendet haben (entweder weil diese eingerichtet wurden oder weil Sie einen FQDN eingegeben haben, der in unterschiedliche IP-Adressen auflöst), versuchen Sie, einen einzigen NTP-Server einzurichten, indem Sie nur eine IP-Adresse eingeben. Dies kann Ihr NTP-bezogenes Problem lösen.
Verfolgen der Kommunikation mit dem NTP-Server
Um zu überprüfen, ob der NTP-Server antwortet oder nicht, ist es möglich, den Datenverkehr zwischen Chrony und dem NTP-Server für einen bestimmten Zeitraum zu verfolgen, während der Server überwacht wird:
1. Starten Sie einen pcap-Trace mit tcpdump auf dem NTP-Port 123 und lassen Sie ihn laufen, bis das Problem auftritt (führen Sie ihn in 'screen' oder mit 'nohup' aus, um zu vermeiden, dass er gestoppt wird, wenn Sie die Verbindung zum Shell-Befehl trennen)
2 . Sobald das Problem erneut auftritt, erhalten Sie eine Systemdiagnose, die den gesamten Verlauf abdeckt, seit Sie den Server auf den DNS-Namen eingestellt haben, bis die Lücke erneut aufgetreten ist. Wenn dies zu einer zu großen Datei führt, rufen Sie einfach die Systemdiagnose für aktuelle Daten auf und kopieren Sie zusätzlich alle Dateien aus /var/log/chrony/ und alle Dateien namens /var/log/syslog* . Denken Sie daran, die Ablaufverfolgung zu stoppen, die Sie in Schritt 1 gestartet haben