Postfix регулярно падает с status=14/ALRM без нехватки памяти: виноват оказался повреждённый журнал systemd, а не почтовый сервер

Разработка ПО
1

Что было. На свежем Debian почтовая служба падает раз в несколько дней: postfix.service: Main process exited, code=killed, status=14/ALRM, пиковая память 430 МБ. Ни OOM-killer, ни лимитов памяти в юните. Автор поставил перезапуск по таймеру как костыль и продолжал искать.

Что нашли. В журнале рядом с падениями: предупреждения сторожевого таймера (watchdog) и сообщения о повреждённых файлах журнала systemd-journald. Служба, которая пишет в журнал через сокет, блокируется, если journald не отвечает; после таймаута приходит SIGALRM, и процесс завершается. Автор остановил зависимые службы, удалил повреждённые файлы журнала, перезапустил systemd-journald, выполнил очистку и проверку; падения прекратились. Подтверждено.

Как проверить журнал.

journalctl --verify                      # PASS / FAIL по каждому файлу
journalctl --disk-usage
systemctl status systemd-journald        # перезапуски, watchdog
ls -la /var/log/journal/*/               # файлы с суффиксом ~ это уже отложенные повреждённые

Повреждённые файлы journald обычно сам переименовывает с ~; если этого не произошло и --verify показывает FAIL, файл можно переместить в сторону (не удаляя, пока не убедитесь, что там нет нужного) и systemctl restart systemd-journald. Ротация вручную: journalctl --rotate && journalctl --vacuum-size=500M.

Почему журнал повреждается. Внезапные выключения виртуальной машины во время записи, заполненный диск (journald не может дописать), проблемы хранилища. После любого из этих событий полезно прогнать --verify.

Как отличить эту причину от проблем самой службы.

  • Падения с сигналом (ALRM, ABRT) без ошибок приложения в его собственном логе.
  • Одновременные странности у нескольких служб (все они пишут в один журнал).
  • Предупреждения systemd-journald о watchdog, Failed to write entry, Journal file … corrupted or uncleanly shut down.
    Если же падает только одна служба и в её логе есть ошибки, искать в ней.

Профилактика. SystemMaxUse= и SystemKeepFree= в journald.conf, чтобы журнал не забивал диск; для маленьких машин Storage=volatile с пересылкой на внешний сборщик; корректное выключение виртуальных машин (ACPI-выключение вместо «стоп» в панели).

Проверка журнала описана в документации systemd.