Logcheck Ignore Logrotate
Я унаследовал систему, использующую оба logcheck и logrotate. Проблема, с которой я столкнулся, заключается в том, что logrotate отправляет неприятное электронное письмо, в котором говорится что-то вроде:
*** WARNING ***: Log file (X) is smaller than last time checked!
Каждый раз, когда logrotate вращает наблюдаемый файл. Похоже, эти инструменты были разработаны для совместной работы, поэтому мне любопытно, как это сделать.
Это кажется простым, и я прошу прощения, если задаю глупый вопрос, который есть где-то в файлах помощи.
Ubuntu 18.04, logcheck 1.3.17, logrotate 3.11.0 - Copyright (C) 1995-2001 Red Hat, Inc.
Дополнительный вопрос, так как copytruncate - это метод, используемый для управления ротацией файлов:
сервис, журналы которого ротаются, является приложением Django / Apache. Сама служба (и файл) не может быть остановлена для процесса ротации, потому что это веб-сервер, который требует времени безотказной работы. Можете ли вы указать мне правильное направление, чтобы начать аккуратно вращать эти файлы? В этом процессе logrotate и logcheck работают вместе довольно четко, но мы недавно обновились до Python 3.1, и это могло вызвать основную проблему.
Второе дополнение: Эта проблема могла быть вызвана раздражением разработчиков некоторыми конфликтующими ограничениями файлов ( Django ограничивает журналы до 4M и logrotate, вращая их на 5M) и усекает сами журналы. Знание о том, что logrotate + logcheck имеет надежную репутацию, было чрезвычайно полезно.
Я использовал logcheck + logrotate в системах Debian в течение 20 лет и в настоящее время использую их на ~60 версиях 8, 9 Debian и 10 серверах, и я имею никогда замеченный то сообщение от logcheck. Таким образом, я сделал немного рытья.
сообщение на самом деле не появляется от logcheck само, а скорее от logtail2 (или, первоначально, logtail), который находится во вспомогательном пакете, который logcheck вводит как зависимость. Согласно logtail описание пакета, главная разница между этими двумя версиями - то, что logtail2 лучше в обработке файлов, которые были повернуты. Учитывая это, я запустил бы путем проверки, который logtail Ваш logcheck использует:
$ grep logtail /usr/sbin/logcheck
LOGTAIL="/usr/sbin/logtail2"
|| error "Could not run logtail or save output"
Проверяют на первой строке, что LOGTAIL устанавливается на [1 113], не logtail.
Предположение, что это использует logtail2 (как это должно), "файл журнала является меньшим" предупреждением, только выпущен, когда файл уменьшается и , inode число остается тем же - другими словами, если файл был переписан оперативный. Это иногда делается для контакта с сервисами, которые не достаточно умны для воссоздавания их файлов журнала по мере необходимости, таким образом, журнал повернут путем копирования его и затем сброса размера к 0 вместо путем переименования его и создания нового файла. Поскольку это - необычное (и скорее hacky, не говоря уже об опасном, поскольку это создает состояние состязания, которое могло позволить сообщениям журнала быть потерянными), способ обработать вращение журнала, я собираюсь предположить, что у Вас есть только небольшое количество файлов журнала, перед которыми предстает это предупреждение.
лучшее решение для этой проблемы состояло бы в том, чтобы зафиксировать Ваши настройки вращения для соответствующих журналов так, чтобы они были обработаны "нормальный" путь вместо путем перезаписи старого журнала. Чтобы сделать это, grep, Ваш logrotate управляет для любых журналов, которые используют copytruncate опция, затем определяют, какие потребности быть сделанным, чтобы заставить те сервисы позволять вращение, не используя copytruncate - способ "в лоб" достигнуть это должно было бы остановить сервис в prerotate сценарий и перезапустить его в [1 120], но обычно существует лучший путь, такой как отправка его определенный сигнал сказать ему вновь открыть свои файлы журнала. (Если Вы ничего не находите, упоминая copytruncate, техника могла бы также быть реализована вручную в сценарии вращения, который необходимо будет искать вручную вместо того, чтобы использовать grep.)
, Если это не опция, Вы смогли создавать, игнорируют правила в logcheck каталог правила, говоря этому проигнорировать тех, которые предупреждают строки, но это зависит от того, обрабатываются ли они как стандартные аномальные записи в журнале или если они обходят проигнорировать систему.