Система 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 ...  

Як і в прикладі, раптова зміна часу може зайняти сотні років.

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

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

Крім того, оскільки це відбувається на більш ніж одному сервері, я припускаю, що це не апаратні проблеми.

Більше інформації про север: це встановлення opentack з одним контролером та кількома обчислювальними вузлами. На кожному сервері працює служба 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 відкладаються довільно довгий час у syslog :

Коротше кажучи, у версії rsyslog, яку я використовую, є помилка, яка затримає повідомлення syslog, яке воно отримало на довільний проміжок часу. Звіт про помилки тут. І оновлення rsyslog вирішило проблему. Це не винна CRON.

Вам слід використовувати зовнішній сервер NTP, синхронізований з джерелом прошарку 1 або 2, щоб уникнути подібних аномалій. Апаратні годинники не є надійними.