Отрицательная разница во времени с `последней перезагрузкой`
Для нескольких серверов лучшим способом оповещения является использование пакета logcheck.
Вы устанавливаете logcheckна стороне сервера и определяете правила для обработки и отправки вам электронной почты по предполагаемым правилам, которые вы хотите активировать по электронной почте.
Таким образом, если завтра вам понадобятся другие правила, отличные от SELinux, вы можете их добавить.
logcheckуже поставляется с набором правил по умолчанию. Я использовал logcheckкакое-то время, когда в прошлом у меня была меньшая инфраструктура -из пары серверов Linux.
Очевидно, что для отправки электронной почты у вас также должен быть сервер MTA с минимальной конфигурацией, чтобы иметь возможность отправлять вам электронную почту. В зависимости от того, является ли электронная почта внутренней или для Gmail, вам придется настроить ее по-разному.
Для более крупной инфраструктуры -я бы посоветовал иметь центральный сервер системных журналов и обрабатывать журналы на этом сервере, однако, судя по вашему ответу о двух серверах, я не буду подробно останавливаться на этом моменте.
Ваш часовой пояс CEST, поэтому текущее смещение UTC должно на 2 часа опережать UTC.
Имеют ли временные метки смысл, если предположить, что 09 :21 на самом деле означает 11 :21, а 09 :29 означает 11 :29 соответственно?
Если это так, то ваша ранняя загрузка может изначально использовать часовой пояс UTC, но скорректировать часовой пояс на CEST в какой-то момент после определения значения временной метки загрузки -.
Использует ли Fedora классический стиль RedHat -/etc/sysconfig/clock? Если это так, в нем может быть параметр, который сообщает, используют ли аппаратные часы UTC или нет. Существует также другое место для той же информации :в третьей строке /etc/adjtimeбудет указано либо UTC, либо LOCAL, чтобы указать, какое время хранится в аппаратных часах. Если эти два местоположения не согласуются друг с другом, я видел подобное поведение. Если вы обнаружите здесь ошибку, перестройте свои initramfs, чтобы исправление также было включено туда.
Является ли ваш /etc/localtimeсимволической ссылкой на /usr/share/zoneinfo/your/timezoneили реальной копией этого файла? Это может иметь значение для генератора initramfs. Если генератор initramfs просто копирует символическую ссылку в initramfs без копирования самого файла, символическая ссылка будет нарушена на этапе загрузки initramfs, и поэтому система может по умолчанию использовать UTC, пока не будет смонтирована реальная корневая файловая система.
(И если вы не нашли ошибку, но временная метка модификации /etc/localtime, /etc/adjtime или /etc/sysconfig/clock новее, чем ваши initramfs, в любом случае пересоберите свои initramfs снова, так как кто-то мог забыл сделать это при изменении настроек часов/часового пояса.)
Кроме того, если это виртуальная машина или физическая машина на блейд-оборудовании, может существовать механизм синхронизации времени виртуальной машины/блейда с часами шасси гипервизора/блейда во время загрузки. Часто такой механизм обеспечивает местное время в интересах систем Windows. Если вы используете синхронизацию NTP,система может загружаться с использованием локального -времени -как -UTC или наоборот, но как только появятся сетевые интерфейсы, она может получить действительное время UTC с сервера NTP, снова вызывая ошибку 2 -часовой прыжок.