Системное время Linux временно скачет

Я видел странное изменение системного времени на некоторых (аппаратных) серверах: во /var/logs/syslog-первых, время, предшествующее каждому сообщению журнала, иногда меняется на случайное и возвращается к нормальному состоянию в следующем сообщении, например:

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

Как и в этом примере, внезапное изменение даты и времени может длиться до сотен лет.

Я могу подтвердить, что сообщения журнала, имеющие странные отметки времени, не приходят ни от какого конкретного процесса - это может происходить случайным образом для каждого.

А продолжительность между двумя ненормальными изменениями времени варьируется от нескольких минут до нескольких часов (однако я подозреваю, что ненормальные изменения времени могут происходить чаще, но многие из них не обнаруживаются в системном журнале, поскольку он не записывает журналы каждую секунду).

Кроме того, поскольку это происходит более чем на одном сервере, я предполагаю, что это не проблема с оборудованием.

Больше информации о серверах: это установка с открытым стеком с одним контроллером и несколькими вычислительными узлами. На каждом сервере запущена служба ntp. Контроллер настроен на получение времени от своих собственных аппаратных часов, а серверы вычислительных узлов синхронизируют время с контроллером. Обратите внимание, что каждый сервер имеет ненормальные изменения времени в своем собственном темпе - похоже, что «неправильное время» не синхронизируется с контроллером через ntp.

Я подозревал, что гостевые системы (виртуальные машины) на вычислительных узлах могут повлиять на время их хост-системы. Но это не может объяснить, почему у контроллера такая же проблема, когда не запущена какая-либо виртуальная машина.

Мне нужен метод, чтобы определить: кто изменил системное время и как это происходит?

Соответствующими аспектами являются версии ядра и эти строки с самого начала процесса загрузки:

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

YMMV и вы не можете использовать TSC или PIT

AFAIK, это ошибка, вызванная тем, что по крайней мере один из ваших процессоров не синхронизирован, в вашем случае, вероятно, он работает слишком быстро.

Это должно быть легко подтвердить, выполнив это:

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

который будет работать dateпротив каждого процессора (при условии, что у вас есть до 8 ядер / потоков). Если мои предположения верны, то один из ваших процессоров будет постоянно иметь неправильное время.

Если это так, то вам следует сначала попробовать обновить ядро, а если это не сработает, поиграйтесь с параметром загрузки clocksource (если это так 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

Смотрите также вывод этого:

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

Похоже, аппаратные часы на сервере вашего контроллера не являются стабильным источником информации о времени. Вы должны настроить свой контроллер для синхронизации его типа с более надежными атомными часами.

Это команда, которую вы можете использовать для обновления аппаратных часов: hwclock -s

Смотрите также:

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

скопировано из: сообщений CRON, задержанных на произвольно долгое время в системном журнале :

Короче говоря, в используемой версии rsyslog есть ошибка, из-за которой полученное сообщение системного журнала задерживается на произвольный промежуток времени. Сообщение об ошибке здесь. И обновление rsyslog решило проблему. Это не вина КРОНА.

Вам следует использовать внешний NTP-сервер, синхронизированный с источником уровня 1 или 2, чтобы избежать таких аномалий. Аппаратные часы не надежны.