служба не работает журнал сторожевой таймер ввод-вывод

systemd-journald убит сторожевым таймером: Watchdog timeout (limit 3min)

В штатной поставке у службы журнала задан срок отметки в три минуты, сигнал прекращения ABRT и безусловный перезапуск. Три минуты без отметки означают, что journald не подвис в вычислениях, а стоит на месте — почти всегда на записи или синхронизации файлов журнала. Сообщения при этом не теряются целиком: сокеты приёма вынесены в отдельные unit и переживают перезапуск службы, но запись, которую journald держал в руках, пропадает, а вместе с перезапуском обрывается и подсчёт частоты сообщений.

Вероятные причины

По порядку: сверху то, что встречается чаще.

Запись упирается в диск

Файлы журнала периодически сбрасываются на диск, и на перегруженном или медленном носителе один такой сброс растягивается на минуты. Отметку послать в это время нечем: служба ждёт ядро.
Файлов журнала накопилось слишком много

Поворот и обрезка проходят по всем файлам каталога. Пока их десятки, это незаметно; когда их сотни, каждая обрезка становится долгой операцией.
Одна служба заливает журнал

Служба в цикле перезапуска или с подробным выводом занимает journald целиком. Ограничение частоты отсекает часть сообщений, но разбор и запись остальных всё равно съедают всё время.
Машине не хватает памяти и служба стоит в подкачке

Журналу назначено преимущество при отборе жертвы нехватки памяти, поэтому его не убивают, — но простаивать в ожидании страниц это не мешает.

Диагностика

Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.

Срок отметки, сигнал прекращения и правило перезапуска — так видно, что сторожевой таймер вообще включён.

systemctl show systemd-journald.service -p WatchdogUSec -p WatchdogSignal -p Restart

Сколько раз за эту загрузку журнал убивали и поднимали заново.

journalctl -b -u systemd-journald --no-pager | grep -iE "Watchdog|Journal started"

Число файлов и занятое место: обе величины прямо влияют на длительность поворота.

ls /var/log/journal/*/ | wc -l; journalctl --disk-usage

Доля времени, которую задачи простаивают в ожидании ввода-вывода. Растущая величина за 10 секунд объясняет залипание лучше любых догадок.

cat /proc/pressure/io

Решение

Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.

1. Запись упирается в диск

Почему происходит: Файлы журнала периодически сбрасываются на диск, и на перегруженном или медленном носителе один такой сброс растягивается на минуты. Отметку послать в это время нечем: служба ждёт ядро.

Как проверить

Посмотрите давление ввода-вывода и объём журнала.

cat /proc/pressure/io
journalctl --disk-usage

Как исправить: Разгрузите носитель или уменьшите поток записей: срок отметки поднимать бесполезно, упор всё равно в диск. Промежуток между сбросами задаётся параметром SyncIntervalSec= в настройках журнала.

2. Файлов журнала накопилось слишком много

Почему происходит: Поворот и обрезка проходят по всем файлам каталога. Пока их десятки, это незаметно; когда их сотни, каждая обрезка становится долгой операцией.

Как проверить

Посчитайте файлы в каталоге журнала и посмотрите занятое место.

ls /var/log/journal/*/ | wc -l
journalctl --disk-usage

Как исправить

Задайте предел числа файлов и объёма (SystemMaxFiles=, SystemMaxUse=) и обрежьте накопленное командой journalctl --vacuum-files= или --vacuum-size=.

[Journal]
SystemMaxUse=2G
SystemMaxFiles=50

3. Одна служба заливает журнал

Почему происходит: Служба в цикле перезапуска или с подробным выводом занимает journald целиком. Ограничение частоты отсекает часть сообщений, но разбор и запись остальных всё равно съедают всё время.

Как проверить

Посмотрите, кто пишет больше всех за последний час.

journalctl --since '1 hour ago' --no-pager -o json 2>/dev/null | head -20000 | grep -oE '"_SYSTEMD_UNIT":"[^"]+' | sort | uniq -c | sort -rn | head -5

Как исправить: Разберитесь с самой болтливой службой: понизьте её уровень записей параметром LogLevelMax= или прекратите цикл перезапуска. Отключать ограничение частоты в такой ситуации — верный способ вернуться к сторожевому таймеру.

4. Машине не хватает памяти и служба стоит в подкачке

Почему происходит: Журналу назначено преимущество при отборе жертвы нехватки памяти, поэтому его не убивают, — но простаивать в ожидании страниц это не мешает.

Как проверить

Посмотрите давление памяти и подкачку.

cat /proc/pressure/memory
free -m

Как исправить: Уберите причину нехватки памяти: пределы для прожорливой службы, отдельный срез или больше памяти на машине. До этого перезапуски журнала будут повторяться.

Пример вывода

Сторожевой таймер сработал на машине с перегруженным диском. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.

systemd[1]: systemd-journald.service: Watchdog timeout (limit 3min)!
systemd[1]: systemd-journald.service: Killing process 412 (systemd-journal) with signal SIGABRT.
systemd[1]: systemd-journald.service: Main process exited, code=dumped, status=6/ABRT
systemd[1]: systemd-journald.service: Failed with result 'watchdog'.
systemd[1]: systemd-journald.service: Scheduled restart job, restart counter is at 2.
systemd-journald[41207]: Journal started
systemd-journald[41207]: System Journal (/var/log/journal/9f0c1d2e.../system.journal) is 128.0M, max 4.0G, 3.8G free.

Связанные ошибки

Failed with result 'watchdog' Состояние watchdog: служба не прислала отметку сторожевому таймеру за отведённое время. Настройка WatchdogSec и разбор.
Журнал занимает слишком много места Журнал разросся: где задаются пределы, как обрезать и почему обрезка иногда не помогает.
Suppressed N messages from unit: часть записей потеряна journald отбросил часть записей из-за ограничения частоты. Как понять, что именно потеряно, и когда предел нужно поднять.
File corrupted or uncleanly shut down, renaming and replacing Журнал повреждён после жёсткой перезагрузки: что означает сообщение и когда нужно вмешательство.
journalctl -b -1: Failed to look up boot, no such boot ID Запрос журнала прошлой загрузки не находит её: журнал непостоянный или обрезан.
rsyslog: ошибка файла состояния при чтении журнала Приёмник журналов теряет записи или читает их заново: файл состояния повреждён или недоступен.
status=211/IOPRIO в systemd Код 211/IOPRIO: не удалось задать приоритет ввода-вывода из IOSchedulingClass= или IOSchedulingPriority=.
В журнале контейнера видны записи хоста Журнал внутри контейнера показывает не то, что ожидалось: каталог журнала хоста проброшен внутрь.

Где встречается чаще всего

systemd-journald.service 7

Источники

systemd.service(5)
WatchdogSec=: без отметки за отведённое время служба помечается неудачной и прекращается сигналом ABRT. официальная документация, systemd 255
сверено 15 сентября 2026
journald.conf(5)
SyncIntervalSec=, SystemMaxUse=, SystemMaxFiles= — промежуток сброса на диск и пределы хранилища. официальная документация, systemd 255
сверено 15 сентября 2026
Проверено на этой машине: systemd 255 (255.4-1ubuntu8.17), Ubuntu 24.04
В unit-файле journald заданы WatchdogSec=3min, Restart=always, RestartSec=0; `systemctl show` подтверждает WatchdogUSec=3min и WatchdogSignal=6 (ABRT). Сам порядок сообщений проверен на своей службе с WatchdogSec=5s: Watchdog timeout → SIGABRT → code=dumped, status=6/ABRT → result «watchdog». собственная проверка, systemd 255
сверено 21 сентября 2026
Журнал рабочего сервера, systemd 255
Отказ самого journald по сторожевому таймеру взят из журнала рабочего сервера (два случая). Воспроизводить его на рабочей машине я не стал: это останавливает приём сообщений на всё время ожидания. наблюдение, systemd 255
сверено 21 сентября 2026