opsjournal.net

Три ловушки logrotate, на которые я наступил

· linuxлоги

logrotate кажется настолько простым, что настраивают его копипастой. Я тоже. Вот три случая, после которых я стал читать man logrotate внимательнее.

1. Приложение продолжает писать в удалённый файл

Симптом: df показывает заполненный диск, а du по каталогу логов показывает немного. Причина: logrotate переименовал файл, приложение держит старый дескриптор и пишет в никуда. Найти такие файлы:

lsof +L1 | grep -i log

Решения два: либо после ротации послать приложению сигнал на переоткрытие логов (postrotate ... endscript), либо, если приложение так не умеет, copytruncate. Второй вариант может потерять несколько строк в момент копирования, имейте в виду.

2. Конфиг есть, а ротации нет

Проверяйте конфиг в режиме отладки, он ничего не меняет:

logrotate -d /etc/logrotate.d/myapp

У меня было два случая: неверные права на каталог (logrotate отказывается работать с каталогом, доступным на запись группе, без директивы su) и ошибка в маске файла. Обе ошибки видны в выводе -d.

3. Ротация раз в сутки, а лог растёт за час

Однажды приложение ушло в цикл ошибок и записало 30 ГБ за ночь. Ротация была daily, до неё не дошло. Теперь для шумных сервисов я задаю ещё и размер:

/var/log/myapp/*.log {
    daily
    maxsize 500M
    rotate 7
    compress
    delaycompress
    missingok
    notifempty
    create 0640 myapp adm
    postrotate
        systemctl kill -s HUP myapp.service
    endscript
}

maxsize работает, только если logrotate запускается чаще, чем раз в сутки. Переведите его таймер на ежечасный запуск: systemctl edit logrotate.timer, OnCalendar=hourly.

Вместо вывода

Для сервисов под systemd я всё чаще вообще не пишу файлы, а оставляю вывод в журнале и ограничиваю его размер через SystemMaxUse= в journald.conf. Меньше движущихся частей.