Системное время Linux временно скачет
Я видел странное поведение системного времени на некоторых (аппаратных) серверах: в /var/logs/syslog время, предшествующее каждому сообщению журнала, иногда меняется на случайное и возвращается к обычному состоянию в следующем сообщении, как показано ниже:
22 февраля 2018 09:09:30 ... 22 февраля 2018 09:09:32 ... 13 января 2610 15:37:42 ... 22 февраля 2018 09:09:33 ... 22 февраля 2018 09:09:34 ...
Как и в этом примере, внезапное изменение даты и времени может длиться до сотен лет.
Я могу подтвердить, что сообщения журнала, имеющие странные метки времени, не приходят ни от какого конкретного процесса - это может происходить случайным образом для каждого.
А продолжительность между двумя ненормальными изменениями времени варьируется от нескольких минут до нескольких часов (однако я подозреваю, что ненормальные изменения времени могут происходить чаще, но многие из них не обнаруживаются в системном журнале, поскольку он не записывает журналы каждую секунду).
Кроме того, поскольку это происходит на нескольких серверах, я предполагаю, что это не проблема с оборудованием.
Больше информации о серверах: это установка с открытым стеком с одним контроллером и несколькими вычислительными узлами. На каждом сервере запущена служба ntp. Контроллер настроен на получение времени от своих собственных аппаратных часов, а серверы вычислительных узлов синхронизируют время с контроллером. Обратите внимание, что каждый сервер имеет ненормальные изменения времени в своем собственном темпе - похоже, что "неправильное время" не синхронизируется с контроллером через ntp.
Я подозревал, что гостевые системы (виртуальные машины) на вычислительных узлах могут повлиять на время их хост-системы. Но это не может объяснить, почему у контроллера такая же проблема, когда не запущена какая-либо виртуальная машина.
Мне нужен метод для определения: кто изменил системное время и как это происходит?
2 ответа
Этот скрипт сообщит вам, когда происходит смещение времени и разница в дереве процессов, и это должно помочь определить это, если оно вызвано процессом, изменяющим системное время. Он распечатает на терминал, а также войдет в timedrift.log внутри текущего рабочего каталога.
#!/bin/bash
oldTime="$(date +%s)"
oldPsOutput="$(ps faux)"
while true; do
sleep 1;
currentTime="$(date +%s)"
oldTimeplusfive="$((($oldTime+5)))"
currentPsOutput="$(ps faux)"
if [[ "$currentTime" -lt "$oldTime" || "$currentTime" -gt "$oldTimeplusfive" ]]
then
(
echo -e '\n\n======================='
echo "currentTime=$currentTime oldTime=$oldTime oldTimeplusfive=$oldTimeplusfive"
echo '-----------------------'
echo "$oldPsOutput"
echo '::::::::::::::::::::::::::'
echo "$currentPsOutput"
) | tee -a timedrift.log
fi
oldPsOutput=$currentPsOutput
oldTime=$currentTime
done
Отдайте должное оригинальному сценарию в необъяснимых скачках времени в ошибке CRON, которую Стоун упомянул в комментарии.
Вы также можете прокомментировать, как будто вы используете rsyslog, и если да, то какая версия? Вы видите это вне области rsyslog (т.е. журналы apache и т. Д.). Эта ошибка выглядит одинаково, и было бы неплохо подтвердить или исключить ее в любом случае.
На самом деле это дубликат комментария @Stone. Просто дайте всем понять, что у них есть ответ.
Короче говоря, в используемой версии rsyslog есть ошибка. Который задержит сообщение системного журнала, которое это получило в течение произвольного промежутка времени. Сообщение об ошибке здесь. И обновление rsyslog решило проблему. Это не ошибка ядра или CRON.