Die Linux-Systemzeit springt zeitlich

Ich habe auf einigen (Hardware-) Servern ein seltsames Verhalten bei der Änderung der Systemzeit festgestellt: In /var/logs/syslogändert sich die Datums- und Uhrzeitangabe vor jeder Protokollnachricht manchmal in eine zufällige und wird in der nächsten Nachricht wieder normal, wie folgt:

Feb 22 2018 09:09:30 ...  
Feb 22 2018 09:09:32 ...  
Jan 13 2610 15:37:42 ...  
Feb 22 2018 09:09:33 ...  
Feb 22 2018 09:09:34 ...  

Wie im Beispiel kann die plötzliche Änderung der Datums- und Uhrzeit bis zu Hunderten von Jahren entfernt sein.

Ich kann bestätigen, dass die Protokollnachrichten mit den seltsamen Zeitstempeln nicht aus einem bestimmten Prozess stammen - sie können nur zufällig für jeden einzelnen auftreten.

Die Dauer zwischen zwei abnormalen Zeitänderungen variiert zwischen einigen Minuten und einigen Stunden (ich vermute jedoch, dass die abnormalen Zeitänderungen häufiger auftreten könnten, aber viele davon werden nicht im Syslog angezeigt, da nicht jede Sekunde Protokolle geschrieben werden).

Da dies auf mehr als einem Server geschieht, gehe ich davon aus, dass es sich nicht um ein Hardwareproblem handelt.

Weitere Informationen zu den Servern: Es handelt sich um eine Openstack-Installation mit einem Controller und einigen Rechenknoten. Auf jedem Server wird ein NTP-Dienst ausgeführt. Der Controller ist so konfiguriert, dass er Zeit von seiner eigenen Hardware-Uhr benötigt, und die Rechenknotenserver synchronisieren die Zeit vom Controller. Beachten Sie, dass jeder Server ungewöhnliche Zeitänderungen in seinem eigenen Tempo aufweist. Es sieht so aus, als ob die "falsche Zeit" nicht über ntp vom Controller synchronisiert wird.

Ich hatte den Verdacht, dass die Gastsysteme (virtuelle Maschinen) auf Rechenknoten die Zeit ihres Hostsystems beeinflussen könnten. Dies kann jedoch nicht erklären, warum der Controller das gleiche Problem hat, wenn keine virtuelle Maschine ausgeführt wird.

Ich brauche eine Methode, um zu erkennen: Wer hat die Systemzeit geändert und wie geschieht dies?

Die relevanten Aspekte sind die Kernel-Versionen und diese Zeilen von Anfang an:

kernel: Fast TSC calibration using PIT
...
kernel: Calibrating delay loop (skipped), value calculated using timer frequency..
...
kernel: Switching to clocksource tsc

YMMV und Sie verwenden möglicherweise nicht TSC oder PIT

AFAIK Dies ist ein Fehler, der dadurch verursacht wird, dass die Uhr mindestens einer Ihrer CPUs nicht synchron ist und in Ihrem Fall wahrscheinlich zu schnell läuft.

Es sollte leicht zu bestätigen sein, indem Sie Folgendes ausführen:

for cpu in {0..8} ; do taskset -c $cpu date ; done

dateDies läuft gegen jede CPU (vorausgesetzt, Sie haben bis zu 8 Kerne / Threads). Wenn meine Vermutung richtig ist, hat eine Ihrer CPUs durchweg die falsche Zeit.

Wenn dies der Fall ist, sollten Sie zuerst versuchen, den Kernel zu aktualisieren. Wenn dies nicht funktioniert, spielen Sie mit dem Clockource-Boot-Parameter (vorausgesetzt, es ist x86-64):

clocksource=    Override the default clocksource
                Format: <string>
                Override the default clocksource and use the clocksource
                with the name specified.
                Some clocksource names to choose from, depending on
                the platform:
                [all] jiffies (this is the base, fallback clocksource)
                [ACPI] acpi_pm
                ...
                [X86-64] hpet,tsc

Siehe auch die Ausgabe davon:

cat /sys/devices/system/clocksource/clocksource*/available_clocksource

Es sieht so aus, als ob die Hardware-Uhr auf Ihrem Controller-Server keine stabile Informationsquelle über die Zeit ist. Sie sollten Ihren Controller so konfigurieren, dass er seinen Typ mit einer zuverlässigeren Atomuhr synchronisiert.

Mit diesem Befehl können Sie Ihre Hardware-Uhr aktualisieren: hwclock -s

Siehe auch:

   -s, --hctosys
          Set the System Time from the Hardware Clock.

          Also set the kernel's timezone value to the local timezone as indicated by the TZ environment variable and/or /usr/share/zoneinfo, as tzset(3) would interpret them.  The obsolete tz_dsttime field of the kernel's time‐
          zone value is set to DST_NONE.  (For details on what this field used to mean, see settimeofday(2).)

          This is a good option to use in one of the system startup scripts.

   -w, --systohc
          Set the Hardware Clock to the current System Time.

kopiert von: CRON-Nachrichten werden im Syslog beliebig lange verzögert :

Kurz gesagt, es gibt einen Fehler in der von mir verwendeten Version von rsyslog, der die empfangene Syslog-Nachricht um einen beliebigen Zeitraum verzögert. Fehlerbericht ist hier. Das Upgrade von rsyslog löste das Problem. Es ist nicht CRONs Schuld.

Sie sollten einen externen NTP-Server verwenden, der mit einer Schicht 1 oder 2-Quelle synchronisiert ist, um solche Anomalien zu vermeiden. Hardware-Uhren sind nicht zuverlässig.