VPS-Uhr geht falsch: Zeitdrift erkennen und beheben

Warum die Uhrzeit Ihres VPS abweicht

Die Uhrzeit eines VPS weicht ab, weil sie nicht korrigiert wird. Der Kernel misst die Zeit anhand eines Hardwarezählers, der etwas zu schnell oder zu langsam läuft. Wenn kein Zeitsynchronisationsdienst ausgeführt wird, wächst dieser kleine Fehler mit jeder Stunde.

In einer virtuellen Maschine gibt es eine weitere Ursache. Ihr Gast teilt sich eine physische CPU mit anderen Gästen. Die Zeit, in der er nicht eingeplant ist, kann er nicht zählen.

Bei einem aktuellen KVM-Gast ist der Zähler selbst nur selten das eigentliche Problem. Die paravirtualisierte kvm-clock-Quelle liest einen Wert, den der Host verwaltet. Ein fehlerfreier Gast bleibt dadurch eng mit seinem Host synchron.

Deutlich falsche Uhrzeiten haben meist einen weniger auffälligen Grund. Es läuft kein Synchronisationsdienst. Oder zwei Dienste laufen gleichzeitig und stören sich gegenseitig. Oder ausgehender UDP-Port 123 verlässt das Netzwerk Ihres Providers nicht.

Ein Gast bezieht seine Zeitsynchronisation vom Host oder über NTP (network time protocol), nicht von seinem eigenen Oszillator.

Was eine falsche Uhrzeit tatsächlich beeinträchtigt

• TOTP-Codes (zeitbasierte Einmalkennwörter) stimmen nicht mehr überein. Dadurch werden Sie von einem Server ausgesperrt, obwohl Passwort und kryptografischer Schlüssel korrekt sind.
• Ein vor einer Minute ausgestelltes Zertifikat wird abgelehnt, und curl gibt SSL certificate problem: certificate is not yet valid aus.
• apt update lehnt ein Repository mit E: Release file for ... is not valid yet (invalid for another 1d 2h 3min 4s) ab.
• Geplante Aufgaben werden zum falschen Zeitpunkt ausgeführt. Ein Zeitsprung kann dazu führen, dass ein Auftrag zweimal ausgeführt wird, während ein anderer übersprungen wird.
• Logs von zwei Servern lassen sich nicht abgleichen. Dadurch muss die Zeitleiste eines Vorfalls anhand von Vermutungen erstellt werden.

Die Toleranz ist kleiner, als die meisten erwarten. Die folgenden Werte sind dokumentierte Standardwerte und keine Messungen aus einem Test.

[
  {
    "label": "TLS certificate boundary",
    "tolerance_seconds": 0,
    "documented_in": "RFC 5280"
  },
  {
    "label": "chrony steps instead of slewing",
    "tolerance_seconds": 1,
    "documented_in": "Debian and Ubuntu chrony.conf"
  },
  {
    "label": "TOTP code, one time step",
    "tolerance_seconds": 30,
    "documented_in": "RFC 6238"
  },
  {
    "label": "Kerberos clock skew",
    "tolerance_seconds": 300,
    "documented_in": "MIT krb5 default"
  }
]

Ein TOTP-Code wird aus einem Zähler berechnet, der alle 30 Sekunden weiterläuft. Die meisten Prüfdienste akzeptieren außerdem jeweils einen Schritt davor oder danach. Eine Abweichung von einer halben Minute in jede Richtung nutzt das gesamte zulässige Zeitfenster. Kerberos ist deutlich toleranter und erlaubt standardmäßig eine Abweichung von 300 Sekunden. Ein Zertifikat ist dagegen überhaupt nicht tolerant: Es wird anhand fester Zeitpunkte mit einer Kulanz von 0 Sekunden geprüft. Eine um eine Sekunde nachgehende Uhr führt daher zur Ablehnung eines ansonsten vollständig gültigen Zertifikats.

Die drei Uhren und welche davon maßgeblich ist

Die Systemuhr ist die maßgebliche Uhr. Sie ist die CLOCK_REALTIME des Kernels: die Anzahl der Sekunden seit dem 1. Januar 1970 UTC, die im Speicher gehalten und von allem gelesen wird, was einen Zeitstempel setzt. Logzeilen, Zertifikatsprüfungen, TOTP-Codes und Änderungszeiten von Dateien stammen von ihr. Wenn jemand sagt, dass die Zeit des Servers falsch ist, ist diese Uhr gemeint.

Die Hardwareuhr, auch RTC (real time clock) genannt, ist ein separater Zähler, der weiterläuft, während die Maschine ausgeschaltet ist. Auf einer physischen Maschine befindet er sich in einem batteriegepufferten Chip. In einem Gast wird er vom Hypervisor emuliert und ist daher weitgehend ein Artefakt des Hosts. Linux liest ihn beim Boot einmal als Startwert und führt danach seinen eigenen Zähler weiter. timedatectl gibt ihn in der Zeile RTC time aus. Verwenden Sie diese Zeile auf einem VPS nicht zur Fehlersuche, weil sie die Zeitvorstellung des Hosts und nicht den Synchronisierungsstatus Ihrer Systemuhr anzeigt. In einem Container gibt es normalerweise überhaupt keinen /dev/rtc, daher schlägt hwclock --show mit hwclock: Cannot access the Hardware Clock via any known method. fehl.

Die Clocksource bestimmt, womit der Kernel zwischen diesen Lesevorgängen zählt. Fragen Sie den Kernel ab, welche Clocksource er ausgewählt hat:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Unter KVM sehen Sie normalerweise kvm-clock. Sie liest einen vom Host verwalteten Wert. Deshalb bleibt ein KVM-Gast auch ohne NTP-Client eine Zeit lang ungefähr korrekt. tsc ist der eigene Zähler der CPU. Xen-Gäste melden xen, und Hyper-V-Gäste melden eine hyperv-Quelle. Lassen Sie diese Einstellung unverändert, sofern es keinen gemessenen Grund für eine Änderung gibt, weil der Kernel bereits die beste vertrauenswürdige Quelle für diese Hardware auswählt.

Einige Hosts stellen dem Gast außerdem ein PTP-Gerät (precision time protocol) bereit. Dadurch kann chrony die Host-Uhr direkt statt über das Netzwerk lesen. Eine Prüfung lohnt sich, aber auf einem gemeinsam genutzten VPS ist das Gerät häufig nicht verfügbar:

sudo modprobe ptp_kvm
ls /dev/ptp*
cat /sys/class/ptp/ptp0/clock_name

Wenn modprobe fehlschlägt oder kein Gerät angezeigt wird, stellt Ihr Host es nicht bereit. In diesem Fall ist Netzwerk-NTP die richtige Lösung. Wenn clock_name die virtuelle KVM-Uhr angibt, kann chrony sie mit einer refclock PHC /dev/ptp0 poll 2-Zeile in seiner Konfiguration verwenden.

Lesen Sie den Zeitstatus auf Ihrem eigenen Rechner

Beginnen Sie mit einem Befehl. Er beantwortet in einer Ansicht die Frage: „Hält etwas diese Uhr korrekt?“

timedatectl

Lesen Sie diese Zeilen, statt einer gemerkten Zahl zu vertrauen:

• Local time und Universal time bezeichnen denselben Zeitpunkt, einmal in Ihrer Zeitzone und einmal in UTC. Sind sie identisch, verwendet der Rechner bereits UTC.
• RTC time ist die oben beschriebene Hardware-Uhr. Auf einem VPS können Sie sie ignorieren.
• Time zone gibt an, was das System zum Formatieren der lokalen Zeit verwendet.
• System clock synchronized ist das eigene Flag des Kernels. Ein Zeit-Daemon setzt es, sobald er seinen Quellen vertraut. no bedeutet daher, dass seit dem Bootvorgang kein Dienst diese Uhr synchronisiert hat.
• NTP service bezieht sich speziell auf systemd-timesyncd. n/a ist auf einem Rechner mit chrony normal, weil timesyncd dort nicht installiert ist. System clock synchronized: yes zusammen mit NTP service: n/a bedeutet, dass chrony die Synchronisierung übernimmt und der Kernel dies bestätigt.

Prüfen Sie als Nächstes, wie groß die Abweichung ist. Schätzen Sie sie nicht anhand Ihres Telefons. Wenn chrony läuft:

chronyc tracking
chronyc sources -v

chronyc tracking gibt die Zahlen aus, die diese Frage beantworten. System time ist die aktuelle Abweichung von der NTP-Zeit, gefolgt vom Wort fast oder slow. Last offset ist die Größe der letzten Korrektur. Frequency ist der von chrony gemessene Gangfehler Ihrer Uhr, den chrony bereits ausgleicht. Leap status sollte Normal anzeigen. Wird Not synchronised angezeigt und ist Reference ID gleich 00000000 (), hat chrony noch keine Quelle ausgewählt.

chronyc sources -v gibt über der Liste eine Legende aus. Sie müssen sich die Symbole daher nicht merken. Zwei Spalten enthalten den größten Teil der relevanten Informationen. Das Statuszeichen am Anfang jeder Zeile gibt an, wie chrony diese Quelle bewertet. * kennzeichnet die Quelle, die derzeit verwendet wird. ? in jeder Zeile bedeutet, dass keine Quelle antwortet. Reach ist der Antwortverlauf der letzten acht Abfragen in Oktalnotation: 377 bedeutet, dass alle acht Abfragen beantwortet wurden, 0 bedeutet, dass keine beantwortet wurde.

Wenn stattdessen systemd-timesyncd zuständig ist:

timedatectl timesync-status
timedatectl show-timesync --all

timesync-status gibt den Server, mit dem der Dienst kommuniziert, das Abfrageintervall und einen Wert für Offset aus. Gibt der Befehl einen Fehler zum Dienst aus, statt den Status anzuzeigen, ist timesyncd auf diesem Rechner nicht der zuständige Daemon. Das beantwortet Ihre Frage bereits.

Für eine grobe Prüfung gegenüber der Außenwelt können Sie ohne zusätzliche Werkzeuge Ihre Uhr mit dem öffentlichen HTTP-Header Date vergleichen. Dieser wird mit einer Auflösung von 1 Sekunde in GMT bereitgestellt:

date -u
curl -sI https://www.cloudflare.com | grep -i '^date:'

Eine Abweichung von 1 oder 2 Sekunden ist hier normal und bedeutet nichts. Eine Abweichung von 1 Minute ist Ihr Fehler.

chrony oder systemd-timesyncd auf einem VPS

Ubuntu und Debian liefern systemd-timesyncd standardmäßig mit. Es ist ein SNTP-Client (Simple Network Time Protocol): Er fragt jeweils einen Server ab und nähert die Systemuhr an dessen Zeit an. Auf einem Rechner, der dauerhaft online ist und anfangs ungefähr die richtige Zeit hat, reicht das aus. Der Ressourcenverbrauch ist nahezu vernachlässigbar.

chrony ist eine vollständige NTP-Implementierung und auf einer virtuellen Maschine die bessere Standardwahl. Die Gründe dafür sehen Sie in der eigenen Ausgabe von chrony. Das Programm fragt mehrere Quellen gleichzeitig ab und verwirft Quellen, die voneinander abweichen. Es misst die Gangabweichung Ihrer Uhr und schreibt sie in eine Drift-Datei. Dadurch korrigiert es die Tendenz der Uhr, statt jedem einzelnen Messwert hinterherzulaufen. Außerdem verarbeitet es die beiden Situationen schnell, die bei einer VM auftreten können, bei einem physischen Rechner jedoch nicht: Der Host kann die VM pausieren, und die VM kann im laufenden Betrieb auf einen anderen Host verschoben werden. Wenn ein PTP-Gerät des Hosts angeboten wird, liest chrony dieses aus.

sudo apt update && sudo apt install -y chrony
systemctl status chrony --no-pager
chronyc sources -v
chronyc tracking

Beobachten Sie die apt-Ausgabe während der Installation. Unter Debian und Ubuntu stellen die Pakete chrony und systemd-timesyncd beide time-daemon bereit. Deshalb entfernt apt timesyncd, während es chrony installiert. Das ist korrekt und beabsichtigt. Führen Sie niemals beide Dienste aus. Zwei Daemons, die dieselbe Uhr setzen, beeinflussen sich gegenseitig. Solange beide laufen, ist keiner der gemeldeten Offsets zuverlässig. Installieren Sie chrony unter Rocky und AlmaLinux mit sudo dnf install -y chrony. Dort heißt die Unit chronyd statt chrony.

Die Konfigurationsdatei befindet sich unter Debian und Ubuntu in /etc/chrony/chrony.conf und unter Rocky und Alma in /etc/chrony.conf. Die Distributionsvorgabe ist für einen VPS bereits sinnvoll. Ändern Sie sie daher nur aus einem konkreten Grund. Zwei Direktiven sollten Sie verstehen:

• Die Zeilen pool und server benennen die Zeitquellen. Mit iburst weist man chrony an, beim Start eine schnelle Folge von Abfragen zu senden. Dadurch erfolgt die erste Synchronisierung innerhalb von Sekunden statt innerhalb von Minuten.
• makestep legt fest, wann chrony die Uhr sprunghaft korrigiert, statt sie schrittweise anzunähern. Prüfen Sie den aktuellen Wert mit grep -n makestep /etc/chrony/chrony.conf. Die Standardvorgabe unter Debian und Ubuntu, makestep 1 3, bedeutet Folgendes: Bei den ersten drei Aktualisierungen nach dem Start von chronyd wird die Uhr umgestellt, wenn sie um mehr als eine Sekunde abweicht. Danach wird sie ausschließlich durch Slewing korrigiert.

Wenn Sie den Zeitverkehr gegen Manipulationen auf dem Übertragungsweg authentifizieren möchten, unterstützt chrony ab Version 4 NTS (Network Time Security). Prüfen Sie zuerst Ihre Version mit chronyd -v. Beachten Sie außerdem, dass NTS neben UDP-Port 123 auch einen offenen ausgehenden TCP-Port 4460 benötigt:

server time.cloudflare.com iburst nts

Starten Sie den Dienst neu und prüfen Sie ihn, bevor Sie ihm vertrauen. Wenn die Konfiguration nicht geparst werden kann, steht überhaupt kein Zeitdienst zur Verfügung. Die Uhr weist Sie darauf nicht hin.

sudo systemctl restart chrony
chronyc sources -v
chronyc tracking

Warum eine Uhr, die um Minuten falsch geht, falsch bleibt

Ein Zeitdaemon kann einen Offset auf zwei Arten korrigieren. Beim Slewing wird die Uhr beschleunigt oder verlangsamt, bis die Abweichung verschwunden ist. Die Zeit läuft dabei immer weiter vorwärts. Zeitstempel werden weder wiederholt noch übersprungen. Beim Stepping springt die Uhr direkt auf den korrekten Wert. Das geht schnell, kann die Uhrzeit aber rückwärts bewegen. Das ist für alles problematisch, was verstrichene Zeit anhand der Systemzeit misst. Deshalb bevorzugen beide Daemons das Slewing.

Diese Bevorzugung erklärt, warum eine stark falsch gehende Uhr lange falsch bleiben kann. chrony führt nur innerhalb des von makestep erlaubten Fensters einen Step aus. Standardmäßig gilt dieses Fenster nur für die ersten Aktualisierungen nach dem Start des Daemons. Findet ein chronyd, der seit einer Woche läuft, anschließend eine Abweichung von vierzig Sekunden, korrigiert er sie per Slewing. Das Korrigieren von vierzig Sekunden dauert dabei deutlich länger, als Sie warten möchten. Erzwingen Sie die Korrektur einmal bewusst zu einem ruhigen Zeitpunkt:

sudo chronyc makestep
chronyc tracking

chronyc tracking sollte jetzt einen System time-Offset nahe null melden. Last offset sollte die Größe der gerade korrigierten Abweichung anzeigen. Überlegen Sie, bevor Sie dies auf einem ausgelasteten Datenbankserver ausführen. Eine rückwärts springende Uhr kann Software verwirren, die davon ausgeht, dass die Zeit nur vorwärts läuft. Den Daemon neu zu starten, ist die schonendere Variante derselben Korrektur, weil das makestep-Fenster beim Start erneut geöffnet wird.

Container teilen die Uhr des Hosts

Ein Container hat keine eigene Systemzeit. Daher gibt es darin nichts zu synchronisieren. Linux-Time-Namespaces virtualisieren nur die monotone Uhr und die Bootzeit-Uhr. CLOCK_REALTIME wird nicht virtualisiert. Ein Container liest daher dieselbe Systemzeit wie der Host, auf dem er läuft. Korrigieren Sie die Uhr auf dem Host. Damit wird sie im selben Moment für jeden Container auf diesem Host korrigiert.

Daraus ergeben sich einige Konsequenzen. Installieren Sie kein chrony oder ntpd in einem Image. Im besten Fall hat dies keine Wirkung. Das Setzen des Datums in einem unprivilegierten Container schlägt mit date: cannot set date: Operation not permitted fehl, weil der Kernel für diesen Aufruf CAP_SYS_TIME verlangt. CAP_SYS_TIME gewährt dem Container keine eigene Uhr. Es erlaubt dem Container, die Uhr des Hosts und damit auch die Uhr jedes anderen Containers zu ändern.

Eine andere Zeitzone in einem Container ist kein Problem der Uhr. Ein Image mit einer eigenen /etc/localtime gibt denselben Zeitpunkt in einer anderen Zeitzone formatiert aus. Dadurch wirkt date falsch, obwohl die Uhr korrekt ist. Setzen Sie TZ=UTC in der Container-Umgebung. Damit verschwindet die Verwirrung. Die gewählte Laufzeitumgebung ändert daran nichts. Der Vergleich von rootless Podman und Docker beschreibt, was sie tatsächlich ändert.

Zeitzonen: UTC auf dem Server, lokale Zeit für Menschen

Stellen Sie die Maschine auf UTC ein und belassen Sie sie dort.

timedatectl list-timezones | grep -i utc
sudo timedatectl set-timezone UTC
timedatectl

UTC kennt keine Sommerzeit. Das ist das entscheidende Argument. Ein täglicher Job um 02:30 in einer Zeitzone mit Sommerzeit läuft an dem Tag, an dem die Uhren zurückgestellt werden, zweimal. An dem Tag, an dem die Uhren vorgestellt werden, läuft er überhaupt nicht. man 8 cron dokumentiert die besondere Behandlung von Verschiebungen um weniger als drei Stunden: Jobs, die durch eine Vorverstellung übersprungen wurden, laufen kurz nach der Änderung. Jobs, die durch eine Rückstellung in eine wiederholte Stunde fallen, laufen nicht ein zweites Mal. Dieses Verhalten ist sinnvoll. Trotzdem sollten Sie es nicht um 03:00 berücksichtigen müssen. Unter UTC läuft der Job an jedem Tag des Jahres genau einmal. Wenn ein Job vollständig fehlt, statt zu einer ungewöhnlichen Uhrzeit zu starten, sind die Gründe, warum ein cron-Job stillschweigend nie ausgeführt wird die wahrscheinlichere Erklärung.

Dasselbe Argument gilt für das Lesen von Logs. journalctl formatiert Zeitstempel in der Systemzeitzone. journalctl --utc erzwingt UTC. Bei zwei Servern in zwei Zeitzonen wird jeder Vorfall zu einer Umrechnungsaufgabe. Unter Zeitdruck durchgeführte Umrechnungen führen dazu, dass Zeitabläufe falsch gelesen werden. Lassen Sie die Systeme mit UTC laufen, speichern Sie Zeitstempel in UTC und rechnen Sie sie erst an der Stelle um, an der ein Mensch sie liest. Wer für einen einzelnen Befehl eine lokale Zeit benötigt, kann sie anfordern, ohne die Maschine umzustellen:

TZ=Europe/Berlin date

Eine weitere Zeile in der Ausgabe von timedatectl gehört in diesen Abschnitt. RTC in local TZ sollte no anzeigen. Die Einstellung yes ist eine Umgehungslösung für den Dual-Boot von Windows auf einem Laptop. Auf einem Server fügt sie lediglich einen Offset hinzu, über den später jemand stolpern kann. Wenn die Einstellung aktiviert ist, gibt timedatectl eine Warnung aus, dass das System so konfiguriert ist, dass es die RTC-Zeit in der lokalen Zeitzone liest.

Fehlerbehebung nach Symptom

Ihr Zwei-Faktor-Code wird auf einem Server abgelehnt. Prüfen Sie die Uhrzeit, bevor Sie etwas anderes prüfen. Der Code stammt aus einem Zähler, der alle 30 Sekunden weiterläuft. Ein Server, der 90 Sekunden nachgeht, berechnet daher einen Code aus einem Zeitintervall, das Ihr Telefon bereits verlassen hat. timedatectl zeigt System clock synchronized: no an, oder chronyc tracking meldet einen großen System time-Versatz. Das ist ein anderer Fehler als eine unmittelbar abgelehnte kryptografische Schlüssel, bei der eine eigene Meldung ausgegeben wird und der in der Anleitung zu Fehlern bei der Public-Key-Authentifizierung behandelt wird.

apt update meldet, dass eine Release-Datei noch nicht gültig ist. Die vollständige Meldung nennt das Repository und die Dauer, für die es noch ungültig bleibt, zum Beispiel is not valid yet (invalid for another 1d 2h 3min 4s). Ihre Uhr geht gegenüber dem Datum in der Release-Datei des Repositorys nach. Diese Dauer misst direkt, wie groß der Rückstand ist. Korrigieren Sie die Uhrzeit. Deaktivieren Sie die Datumsprüfung von apt nicht, nur um den Fehler zu umgehen. Diese Prüfung verhindert, dass Ihnen jemand einen veralteten Paketindex liefert.

Jede Quellzeile zeigt den Status „nicht erreichbar“ an, und Reach ist 0. Es antwortet nichts. Prüfen Sie daher den ausgehenden Netzwerkverkehr statt Ihre Konfiguration. NTP verwendet ausgehend UDP-Port 123. Einige Netzwerke filtern oder umleiten diesen Verkehr. sudo chronyc ntpdata gibt Zähler für jede Quelle aus, darunter Total TX und Total RX. Wenn der TX-Zähler steigt, während RX bei 0 bleibt, verlassen Ihre Pakete den Host, aber es kommt nichts zurück. Das deutet auf eine Firewall zwischen Ihnen und der Quelle hin.

Die Uhrzeit war korrekt und sprang dann. Host-Ereignisse können dies verursachen. Ein wiederhergestellter Snapshot, ein pausierter Gast oder eine Live-Migration auf einen anderen Host kann dazu führen, dass die Zeit im Gast hinter der tatsächlichen Zeit zurückbleibt. chrony erkennt dies bei der nächsten Abfrage und korrigiert die Uhrzeit. systemd-timesyncd wartet möglicherweise zuerst ein langes Abfrageintervall ab. Stellen Sie mit systemctl is-enabled chrony sicher, dass der Daemon beim Booten startet. Ein manuell gestarteter Daemon läuft nach dem nächsten Reboot nicht mehr.

Der Versatz ist klein, stabilisiert sich aber nie. Prüfen Sie CPU-Steal-Time. Ein Gast, der zum fälligen Zeitpunkt eines Timer-Interrupts nicht eingeplant wird, erhält seine Messwerte verspätet. Dadurch schwankt der Versatz, statt sich einzupendeln. top zeigt dies als den Wert st in der CPU-Zeile an. CPU-Steal-Time auf einem gemeinsam genutzten Host auswerten erklärt die Bedeutung dieses Werts und welche Maßnahmen möglich sind.

Ein gerade ausgestelltes Zertifikat wird als noch nicht gültig abgelehnt. curl gibt SSL certificate problem: certificate is not yet valid aus. Browser zeigen eine ähnliche Meldung an. Das Zertifikat ist in Ordnung. Die Uhr, die es prüft, geht nach. Der Fehler kann auf beiden Systemen liegen. Prüfen Sie daher den Client und den Server. Wenn der Server, der das Zertifikat ausgestellt hat, die falsche Uhrzeit hat, behandelt die Anleitung zu Certbot- und Nginx-Zertifikaten die Erneuerung in derselben Konfiguration.

Nehmen Sie die Prüfung in die bereits ausgeführten Kontrollen auf

Die Zeitsynchronisierung ist eine Einstellung zur Boot-Zeit, die Monate später unbemerkt fehlschlagen kann. Genau für solche Fälle ist eine Routineprüfung zuverlässig, das Gedächtnis jedoch nicht. timedatectl und chronyc tracking sind zusammen in zwei Sekunden gelesen. Führen Sie sie als Teil der ersten zehn Minuten auf einem neuen VPS aus und wiederholen Sie die Prüfung, wenn Sie die reguläre Checkliste für die Linux-Serverwartung durcharbeiten. Wenn die Prüfung automatisch ausgeführt werden und Sie warnen soll, sobald der Offset größer wird, beschreibt einen systemd-Dienst und -Timer erstellen das Muster für eine kleine Unit, die nach einem Zeitplan Meldungen ausgibt. Eine solche Prüfung ist ein kurzes Skript und kein Daemon. Daher benötigt sie Type=oneshot statt des Standardwerts. Die Übersicht über systemd-Diensttypen erklärt, warum der falsche Typ zu einer Unit führt, die einen Erfolg meldet, den sie nicht erzielt hat.

FAQ

Wie prüfe ich, ob die Uhr meines VPS synchronisiert ist?

Führen Sie timedatectl aus und lesen Sie die Zeile System clock synchronized. Das ist das eigene Flag des Kernels. Es wird von dem Daemon gesetzt, der die Uhr synchronisiert. Daher ist yes zusammen mit NTP service: n/a auf einem System mit chrony normal und korrekt. Für die Größe der Abweichung führen Sie chronyc tracking aus und lesen Sie System time. Alternativ können Sie timedatectl timesync-status ausführen und Offset lesen, wenn systemd-timesyncd die Synchronisierung übernimmt. Für einen Vergleich mit einer Quelle außerhalb des Systems vergleichen Sie date -u mit dem Header Date, den eine beliebige HTTPS-Site zurückgibt.

Sollte ich auf einem VPS chrony oder systemd-timesyncd verwenden?

Verwenden Sie für wichtige Systeme chrony. systemd-timesyncd ist ein SNTP-Client, der einem Server folgt. Er eignet sich für ein System, das dauerhaft online ist und bereits mit einer weitgehend korrekten Uhrzeit startet. chrony fragt mehrere Quellen ab, verwirft voneinander abweichende Quellen, ermittelt die Gangabweichung Ihrer Uhr und synchronisiert sie nach einer Host-Pause oder einer Live-Migration schnell wieder. Die Installation von chrony unter Debian oder Ubuntu entfernt systemd-timesyncd automatisch, weil beide Pakete time-daemon bereitstellen. Führen Sie niemals zwei Zeit-Daemons gleichzeitig aus.

Warum schlagen meine TOTP-Codes auf einem Server fehl, funktionieren aber überall sonst?

Weil ein TOTP-Code von der aktuellen Uhrzeit abhängt. Der Code basiert auf einem Zähler, der alle 30 Sekunden weitergeschaltet wird. Daher müssen der Server und Ihr Telefon denselben Zeitschritt verwenden. Die meisten Prüfsysteme akzeptieren einen Zeitschritt davor oder danach. Dadurch entsteht in jeder Richtung ein Spielraum von ungefähr einer halben Minute. Prüfen Sie timedatectl auf diesem Server. Wenn System clock synchronized den Wert no enthält, beheben Sie die Zeitsynchronisierung. Danach stimmen die Codes wieder überein, ohne dass Sie das gemeinsame Secret ändern müssen.

Kann ich die Uhrzeit innerhalb eines Docker-Containers einstellen?

Nein, und das ist auch nicht erforderlich. Ein Container verwendet CLOCK_REALTIME des Hosts gemeinsam, weil Linux-Zeit-Namespaces nur die monotone Uhr und die Bootzeit-Uhr virtualisieren. Ein Container ohne erhöhte Berechtigungen erhält date: cannot set date: Operation not permitted. Das Hinzufügen von CAP_SYS_TIME ermöglicht die Änderung der Uhr des Hosts, statt dem Container eine eigene Uhr zu geben. Synchronisieren Sie stattdessen den Host. Eine abweichende lokale Uhrzeit innerhalb eines Containers ist eine Zeitzoneneinstellung. Setzen Sie daher TZ in der Container-Umgebung.

Sollte ein Server UTC oder die lokale Zeit verwenden?

UTC. Wenden Sie die lokale Zeit erst an, wenn eine Person die Ausgabe liest. UTC ändert sich nicht durch die Sommerzeit. Daher läuft ein täglicher Job das ganze Jahr über einmal pro Tag, und Zeitstempel verschiedener Server stimmen ohne Umrechnung überein. Setzen Sie UTC mit sudo timedatectl set-timezone UTC. Wer eine lokale Anzeige benötigt, kann einem einzelnen Befehl beispielsweise TZ=America/New_York date voranstellen. Dadurch ändert sich die Systemuhr nicht.