Server-Uhrzeit: chrony-Quellen und Synchronisation prüfen

Als abgelaufen eingestufte Zahlungs-Callbacks, sporadisch ungültige Anmeldetoken und eine vertauschte Reihenfolge prozessübergreifender Logeinträge können dieselbe Ursache haben: Die Systemuhr wird nicht stabil synchronisiert. Eine Änderung der Zeitzone wirkt sich nur auf die Darstellung aus und korrigiert keine Zeitabweichung. Die Fehlersuche sollte daher bei den Zeitquellen, dem Synchronisationsstatus und den Toleranzen der Anwendung ansetzen – nicht bei einem Befehl, der die Uhr zwangsweise stellt.

Dieser Beitrag beschreibt anhand von chrony unter Debian 12 einen Ablauf aus Quellenprüfung, Bewertung der Abweichung, Einrichtung einer Synchronisationsschranke und Kontrolle nach der Wiederherstellung. Die Zugangsdaten für einen Dedicated Server von AmdMetal sind nach der Zahlung in der Konsole einsehbar; der Zugriff erfolgt per SSH. Bei mehreren IPv4-Adressen wird die erste Adresse verwendet. Die folgenden Schritte verändern keine Netzwerkadressen und erfordern keine öffentlich zugänglichen Verwaltungsports.

1. Ausgangszustand erfassen: Anzeige und Korrektur unterscheiden

Halten Sie zunächst Systemzeit, Zeitzone, Kernelversion und den aktuell verwendeten Zeitsynchronisationsdienst fest. Anwendungslogs sollten einheitlich ein Zeitformat mit Zeitzonenangabe verwenden. Dokumentieren Sie bei der Fehlersuche zusätzlich die UTC-Zeit, damit reine Darstellungsunterschiede nicht mit einer driftenden Uhr verwechselt werden.

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

Die Synchronisationsangaben von timedatectl liefern Anhaltspunkte, ersetzen aber keine Prüfung der Zeitquellen. Stellen Sie außerdem sicher, dass nicht gleichzeitig andere Zeitdienste oder Aufgaben des Konfigurationsmanagements die Uhr verstellen. Virtuelle Maschinen auf dem Host müssen jeweils separat geprüft werden: Ein korrekt synchronisierter Host bedeutet nicht automatisch, dass auch die Gastsysteme korrekt synchronisiert sind.

Falls chrony noch nicht installiert ist, lässt es sich aus den Paketquellen des Systems installieren. Dabei kann jedoch der Dienst bereits mit der von der Distribution vorgegebenen Konfiguration starten. Auf einem Server mit laufenden Anwendungen sollten Sie deshalb vorab prüfen, welche Konfiguration wirksam wird und welche Aktionen die Paketinstallation ausführt, statt erst nach der Installation zu beobachten, was passiert.

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

Zeitsprünge der Echtzeituhr können laufende Datenbanken, Authentifizierungsdienste und Aufgabenplaner beeinträchtigen. Führen Sie weder date -s noch chronyc makestep aus, bevor die Auswirkungen auf die Anwendungen bewertet wurden. Versuchen Sie auch nicht, die Uhr durch wiederholte Neustarts des Zeitdienstes „zu reparieren“.

2. Zeitquellen prüfen: Erreichbarkeit ist kein Vertrauensnachweis

Prüfen Sie nach der Installation die Hauptkonfiguration und alle darin eingebundenen Dateien. Verwenden Sie ausschließlich Zeitquellen, die Ihre Organisation freigegeben hat. Übernehmen Sie keine öffentlichen Adressen unbekannter Herkunft, und betrachten Sie eine bestimmte fest eingetragene Quelle nicht als von AmdMetal bereitgestellte Infrastruktur.

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

server und pool definieren die Quellen; eingebundene Verzeichnisse können zusätzliche Einstellungen einbringen. Doppelte Quellen müssen anhand der tatsächlich angesprochenen Server erkannt und bereinigt werden. Auch unterschiedliche Namen können letztlich auf dieselbe Infrastruktur verweisen. Die Zahl der Konfigurationszeilen sagt daher nichts Verlässliches über die Unabhängigkeit der Quellen aus.

In sources -v kennzeichnet * die aktuell ausgewählte Synchronisationsquelle, + eine Quelle, die in die kombinierte Zeitbestimmung einfließt, und ? eine Quelle, die derzeit nicht zur Auswahl verwendet werden kann. Gründe dafür können unter anderem fehlende Erreichbarkeit oder zu wenige Messwerte sein. Reach zeigt den Erreichbarkeitsverlauf als Oktalzahl an. 377 bedeutet, dass auf die letzten acht Abfragen jeweils eine Antwort eingegangen ist – nicht, dass die gelieferte Zeit zwangsläufig korrekt ist.

Reihenfolge bei der Fehlersuche an Zeitquellen

Prüfen Sie zuerst die Namensauflösung, anschließend die Route zur Quelladresse und die Regeln für ausgehenden Verkehr. Beobachten Sie danach, ob fortlaufend neue Messwerte eintreffen. Eine erreichbare NTP-Antwort bestätigt lediglich, dass die Kommunikation funktioniert. Eine fehlerhafte Quellzeit, asymmetrische Verzögerungen oder widersprüchliche Messwerte können die Quellenauswahl weiterhin beeinträchtigen. Lockern Sie nicht pauschal die Firewall des gesamten Servers, nur um ein ? zu beseitigen.

3. Abweichungen bewerten: Nicht auf einen einzelnen Wert verlassen

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

Reference time sollte regelmäßig aktualisiert werden. Steht Leap status auf Not synchronised, ist die Abnahme nicht bestanden. System time bezeichnet die von chrony geschätzte verbleibende Korrektur. Ein Wert nahe null ist kein unabhängiger Nachweis dafür, wie groß die Abweichung von der tatsächlichen UTC ist.

Last offset und RMS offset beschreiben die Messwerte und ihre statistische Auswertung. Root delay und Root dispersion geben Hinweise auf den Pfad zur Referenzuhr und die damit verbundene Unsicherheit. Diese Felder müssen zusammen mit dem Zustand der Quellen bewertet werden. Ein einzelner herausgegriffener Dezimalwert ist kein ausreichender Nachweis für eine erfolgreiche Synchronisation.

Erfassen Sie nach Möglichkeit mehrere aufeinanderfolgende Ausgaben über mehrere Abfrageintervalle hinweg. Die Einregelung nach einem Kaltstart und der erneute Aufbau von Messwerten nach einer Netzwerkstörung sind getrennt vom stabilen Betrieb zu beurteilen. Ändern Sie nicht ständig die Konfiguration, nur um einen einzelnen Messwert zu verkleinern. Sonst lässt sich kaum noch erkennen, welche Änderung tatsächlich Wirkung hatte.

4. Eine zeitlich begrenzte Synchronisationsschranke einrichten

Für zeitabhängige Anwendungen lässt sich beim Start oder bei Prüfungen vor einer Bereitstellung eine begrenzte Wartephase vorsehen. Die folgenden Werte sind lediglich ein technisches Beispiel. Geeignete Grenzwerte müssen anhand der Token-Gültigkeitsdauer, der Audit-Anforderungen und der Anwendungstests festgelegt werden; sie sind keine Leistungszusage.

chronyc waitsync 12 0.05 0 5

Dieser Befehl prüft höchstens zwölfmal im Abstand von fünf Sekunden. Er verlangt, dass chrony synchronisiert ist und die verbleibende Korrektur unter 0.05 Sekunden liegt. Der dritte Parameter ist null und legt damit keine zusätzliche Grenze für skew fest. Ein erfolgreicher Exit-Status bedeutet, dass diese Bedingungen erfüllt sind. Er garantiert nicht, dass die Abweichung von der tatsächlichen UTC weniger als fünfzig Millisekunden beträgt.

Automatisierte Aufgaben müssen den Exit-Code auswerten und dürfen Fehlermeldungen nicht unterdrücken:

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

Schlägt die Prüfung fehl, müssen die davon abhängigen Startschritte blockiert und die Betriebsverantwortlichen benachrichtigt werden. Ein Zeitsprung darf nicht automatisch als Reparatur ausgelöst werden. Auch network-online.target betrifft lediglich die Bereitschaft des Netzwerks und belegt keine abgeschlossene Uhrensynchronisation.

Den Fehlerfall der Synchronisationsschranke testen

Prüfen Sie in einer isolierten Testumgebung, ob die Schranke ohne verfügbare Quellen mit einem von null verschiedenen Exit-Code endet. Stellen Sie die Quellen anschließend wieder bereit und testen Sie den Erfolgsfall. Verstellen Sie nicht die globale Systemzeit auf einem produktiven Dedicated Server, um künstlich eine Abweichung zu erzeugen. Das würde alle Dienste gleichzeitig beeinflussen und die Logs verfälschen, die zur zeitlichen Einordnung eines Vorfalls benötigt werden.

5. Wiederherstellung prüfen und nachvollziehbare Nachweise sichern

Wurden Quellen manuell als offline markiert, führen Sie chronyc online erst aus, nachdem die Netzwerkverbindung nachweislich wiederhergestellt ist. Falls zusätzliche Messwerte benötigt werden, können Sie für die konfigurierten Quellen einmalig chronyc burst 4/4 ausführen. Beobachten Sie anschließend erneut die Quellenauswahl und die Ausgabe von tracking. Wiederholen Sie den Aufruf nicht in einer Schleife, die nur unnötige Anfragen erzeugt.

Achten Sie bei der Prüfung von makestep besonders auf Konfigurationen wie makestep 1.0 3: Sie erlauben bei den ersten Uhrenaktualisierungen nach dem Start einen unmittelbaren Zeitsprung, wenn die Abweichung den Grenzwert überschreitet. Ein Neustart des Dienstes kann diese Phase erneut auslösen. „Einfach neu starten“ ist deshalb kein risikofreier Eingriff. Ist ein größerer Zeitsprung tatsächlich erforderlich, müssen zuvor die betroffenen Anwendungen isoliert werden und ein Wiederherstellungsplan vorliegen.

Die abschließende Prüfung sollte Folgendes umfassen:

• Eine geeignete Quelle ist ausgewählt. Die Referenzzeit schreitet fort und bleibt nicht über längere Zeit auf einem alten Messwert stehen.
• Verbleibende Korrektur und Unsicherheit liegen innerhalb der für die Anwendung festgelegten Grenzen. Bei fortlaufender Beobachtung ist keine deutliche Verschlechterung erkennbar.
• Sowohl der Erfolgsfall als auch der Fehlerausgang der Synchronisationsschranke wurden getestet; die Benachrichtigungen kommen an.
• Authentifizierung, Callbacks und die Reihenfolge der Logeinträge wurden auf Anwendungsebene erneut geprüft. Es wurde nicht nur kontrolliert, ob die Prozesse noch laufen.
• Konfigurationsänderungen, Befehlsausgaben und Beobachtungszeiträume sind dokumentiert. Für Quelladressen in den Logs gelten die entsprechenden Zugriffsberechtigungen.

Für Laufzeitmessungen und die Steuerung von Zeitüberschreitungen sollte bevorzugt eine monotone Uhr verwendet werden. Die Echtzeituhr ist dagegen für fachliche Zeitstempel vorgesehen. Werden die Zeitmessung der Anwendung und die Abnahme der Host-Synchronisation getrennt behandelt, kann eine Uhrkorrektur normale Laufzeiten nicht plötzlich negativ erscheinen lassen. Zugleich bleiben spätere Störungsaufzeichnungen nachvollziehbar.

Häufig gestellte Fragen