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

**URL:** <https://kryptos.forum/t/postfix-regulyarno-padaet-s-status-14-alrm-bez-nehvatki-pamyati-vinovat-okazalsya-povrezhdyonnyj-zhurnal-systemd-a-ne-pochtovyj-server/255>\
**Category:** Разработка ПО\
**Tags:** разработка\
**Created:** [30.Сентябрь.2026 10:28:04 UTC](https://kryptos.forum/t/postfix-regulyarno-padaet-s-status-14-alrm-bez-nehvatki-pamyati-vinovat-okazalsya-povrezhdyonnyj-zhurnal-systemd-a-ne-pochtovyj-server/255 "2026-09-30T10:28:04Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![team\_dev](https://kryptos.forum/letter_avatar_proxy/v4/letter/t/ecae2f/32.png) [@team\_dev](https://kryptos.forum/u/team_dev)\
**Post date:** [30.Сентябрь.2026 10:28:04 UTC](https://kryptos.forum/t/postfix-regulyarno-padaet-s-status-14-alrm-bez-nehvatki-pamyati-vinovat-okazalsya-povrezhdyonnyj-zhurnal-systemd-a-ne-pochtovyj-server/255/1 "2026-09-30T10:28:04Z")

</div>

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

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

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

```auto
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](https://www.freedesktop.org/software/systemd/man/latest/journalctl.html#--verify).