Czas systemu Linux tymczasowo skacze

Widziałem dziwne zachowanie zmieniające się w czasie systemowym na niektórych (sprzętowych) serwerach: w /var/logs/syslogczasie data poprzedzająca każdy komunikat dziennika czasami zmienia się na losową i wraca do normy w następnym komunikacie, jak poniżej:

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 ...  

Podobnie jak w przykładzie, nagła zmiana daty może nastąpić nawet za setki lat.

Mogę potwierdzić, że komunikaty dziennika zawierające dziwne znaczniki czasu nie pochodzą z żadnego konkretnego procesu - mogą się zdarzyć losowo dla każdego.

Czas trwania między 2 nieprawidłowymi zmianami czasu waha się od kilku minut do kilku godzin (podejrzewam jednak, że nieprawidłowe zmiany czasu mogą zdarzać się częściej, ale wiele z nich nie jest ujawnianych w syslog, ponieważ nie zapisuje dzienników co sekundę).

Ponadto, ponieważ dzieje się to na więcej niż jednym serwerze, zakładam, że nie jest to problem sprzętowy.

Więcej informacji o serwerach: są one instalacją typu openstack z jednym kontrolerem i kilkoma węzłami obliczeniowymi. Każdy serwer ma uruchomioną usługę NTTP. Kontroler jest skonfigurowany tak, aby pobierał czas z własnego zegara sprzętowego, a serwery węzłów obliczeniowych synchronizowały czas z kontrolera. Zauważ, że każdy serwer ma nietypowe zmiany czasu we własnym tempie - wygląda na to, że „zły czas” nie jest zsynchronizowany z kontrolerem przez ntp.

Podejrzewałem, że systemy-goście (maszyny wirtualne) w węzłach obliczeniowych mogą wpływać na czas systemu hosta. Ale to nie może wyjaśnić, dlaczego kontroler ma ten sam problem, gdy nie działa żadna maszyna wirtualna.

Potrzebuję metody wykrywania: kto zmienił czas systemowy i jak to się dzieje?

Istotnymi aspektami są wersje jądra i następujące linie od samego początku procesu rozruchu:

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

YMMV i możesz nie używać TSC ani PIT

AFAIK jest to błąd, który jest spowodowany brakiem synchronizacji zegara co najmniej jednego z procesorów, w twoim przypadku prawdopodobnie działa zbyt szybko.

Potwierdzenie tego powinno być łatwe:

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

który będzie działał datena każdym procesorze (zakładając, że masz do 8 rdzeni / wątków). Jeśli zgaduję, że jeden z twoich procesorów konsekwentnie będzie miał niewłaściwy czas.

W takim przypadku powinieneś najpierw zaktualizować jądro, a jeśli to nie zadziała, baw się z parametrem rozruchowym clocksource (zakładając, że 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

Zobacz także wynik tego:

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

Wygląda na to, że zegar sprzętowy na serwerze kontrolera nie jest stabilnym zasobem informacji o czasie. Należy skonfigurować kontroler, aby synchronizował jego typ z bardziej niezawodnym zegarem atomowym.

Oto polecenie, którego możesz użyć do zaktualizowania zegara sprzętowego: hwclock -s

Zobacz też:

   -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.

skopiowane z: Wiadomości CRON są opóźnione przez dowolny czas w syslog :

Krótko mówiąc, w wersji rsyslog, której używam, jest błąd, który opóźnia otrzymaną wiadomość syslog na dowolny czas. Raport o błędach jest tutaj. A aktualizacja rsyslog rozwiązała problem. To nie jest wina CRON.

Powinieneś użyć zewnętrznego serwera NTP zsynchronizowanego ze źródłem warstwy 1 lub 2, aby uniknąć takich anomalii. Zegary sprzętowe nie są niezawodne.