Я унаследовал систему, использующую как 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 ограничивает журналы до 4 Мбайт, а logrotate вращается со скоростью 5 Мбайт) и усечением самих журналов. Знание того, что logrotate + logcheck имеет надежную репутацию, было чрезвычайно полезно.
Я использовал logcheck+logrotate в системах Debian в течение 20 лет, и в настоящее время использую их на ~ 60 серверах Debian версий 8, 9 и 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 устанавливается на logtail2не logtail.
Предполагая, что он использует logtail2 (как и должно быть) предупреждение "файл журнала меньше" выдается только при сжатии файла. и номер inode остается прежним - другими словами, если файл был перезаписан на месте. Иногда это делается для работы со службами, которые недостаточно умны, чтобы воссоздавать свои файлы журнала по мере необходимости, поэтому журнал вращается путем его копирования и последующего сброса размера на 0 вместо его переименования и создания нового файла. Поскольку это необычный (и довольно хакерский, не говоря уже о рискованном, поскольку он создает состояние гонки, которое может позволить потерять сообщения журнала) способ обработки ротации журналов, я собираюсь предположить, что у вас есть только небольшое количество файлы журнала, для которых появляется это предупреждение.
Лучшим решением этой проблемы было бы исправить ваши настройки ротации для соответствующих журналов, чтобы они обрабатывались «обычным» способом, а не перезаписывали старый журнал. Сделать это, grep ваши правила logrotate для любых журналов, которые используют copytruncate вариант, а затем определите, что нужно сделать, чтобы эти службы разрешили ротацию без использования copytruncate - способ грубым перебором для достижения этой цели - остановить службу в prerotate скрипт и перезапустите его в postrotate, но обычно есть способ лучше, например, послать ему конкретный сигнал, чтобы он снова открыл свои файлы журнала. (Если вы не найдете ничего упоминания copytruncate, этот метод также может быть реализован вручную в сценарии поворота, который вам придется искать вручную вместо использования grep.)
Если это не вариант, вы можете создать правила игнорирования в logcheck директория правил, указывающая ему игнорировать эти строки предупреждений, но это зависит от того, обрабатываются ли они как стандартные аномальные записи журнала или обходят систему игнорирования.