Czas systemu Linux tymczasowo skacze

11

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?

Zhaohui Yang
źródło
Czy pokazane znaczniki czasu są rzeczywistymi znacznikami czasu? Czy masz więcej przykładów do pokazania?
Kusalananda
Czy omawiane serwery są serwerami typu blade? Jeśli tak, to jednostka zarządzająca obudową typu blade może próbować zsynchronizować zegary poszczególnych serwerów typu blade. Znajomość rzeczywistego modelu serwera byłaby konieczna do wyszukiwania znanych błędów sprzętowych zegara.
telcoM,
Czy możesz również monitorować czas CWU hwclock? Jeśli to też się zmieni w tym czasie ...
Jaroslav Kucera,
3
Zauważ, że syslogd po prostu zapisuje treść wiadomości, którą wysłał z dowolnego procesu, do odpowiedniego pliku dziennika; znacznik czasu jest faktycznie wysyłany w wiadomości, nie jest generowany przez syslogd. Być może więc coś psuje wiadomości lub jeśli jest to jeden z rodzajów procesów, być może ten proces wysyła błędne wiadomości syslog. FYI format jest opisany przez RFC3164; część daty / godziny jest wysyłana zwykłym kodem ASCII.
wurtel
Proszę podać wszystkie informacje z wielokrotnie opublikowanego duplikatu na stronie superuser.com/questions/1298404 w pytaniu .
JdeBP,

Odpowiedzi:

1

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
V13
źródło
0

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.
Dmitriy Kupch
źródło
-1

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.

Tlen
źródło