Я видел странное поведение изменения системного времени на некоторых (аппаратных) серверах: в / 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.
Я подозревал, что гостевые системы (виртуальные машины) на вычислительных узлах могут влиять на системное время хоста. Но это не может объяснить, почему у контроллера такая же проблема, когда не запущена никакая виртуальная машина.
Мне нужен метод для определения: кто изменил системное время и как это происходит?
Этот сценарий сообщит вам, когда происходит дрейф времени и разница в дереве процессов, и это должно помочь идентифицировать это, если это вызвано процессом, изменяющим системное время. Он будет печатать на терминале, а также входить в 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.