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


8

Я видел странное поведение системного времени на некоторых (аппаратных) серверах: в / 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
Можете ли вы показать вывод hwclockцикла? Что-то как:while true; do hwclock; sleep 5; done
Shodanshok

на каждом сервере запущена служба ntp: как клиент или как сервер? через systemd или вне systemd через "старый" сервис ntp? для меня это выглядит как предоставление времени NTP. у нас была проблема, из-за которой мы записывали файлы журналов до того, как наше время было синхронизировано (до подключения к сети, что приводит к скачкам временных меток) у systemd есть цель, на которую вы, возможно, захотите положиться systemd [1]: время было изменено systemd [1]: Достигнута цель Системное время синхронизировано.
Деннис Нольте

похоже, какая-то загрузка даты выполняется как cron и не очень хорошо проверяет время. Найдите его, удалите и замените на ntpd, который не реагирует на большие временные сдвиги.
Данблэк

Мы получили новые результаты и обнаружили, что проблему можно сузить до задержек сообщений CRON в системном журнале. Поэтому я разместил еще один вопрос . Пожалуйста, посмотрите там.
Чжаохуэй Ян

3
Возможно, это ваша ошибка: необъяснимые скачки времени в CRON, который был исправлен в rsyslog - 7.4.4-1ubuntu2.7 .
Камень

Ответы:


1

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


0

На самом деле это дубликат комментария @Stone. Просто дайте всем понять, что у них есть ответ.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.