SystemdDoctor
мешает работе журнал ресурсы

Suppressed N messages from unit: часть записей потеряна

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

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

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

  1. Служба пишет слишком часто

    Отладочный вывод или цикл ошибок даёт сотни записей в секунду. Предел срабатывает, и часть картины исчезает.

  2. Предел мал для нормальной работы службы

    Некоторые службы штатно пишут много: прокси, брандмауэры, почта. Для них предел по умолчанию тесен.

  3. Разбор ведётся по неполному журналу

    Главная опасность не в потере записей, а в неверных выводах: искомой строки может не быть просто потому, что её отбросили.

Диагностика

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

Сколько записей и от кого было отброшено.

journalctl -b --no-pager | grep -i suppressed | tail

Действующие пределы частоты.

systemd-analyze cat-config systemd/journald.conf | grep -i RateLimit

Пределы для конкретной службы.

systemctl show myapp.service -p LogRateLimitIntervalSec -p LogRateLimitBurst

Решение

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

1. Служба пишет слишком часто
Почему происходит
Отладочный вывод или цикл ошибок даёт сотни записей в секунду. Предел срабатывает, и часть картины исчезает.
Как проверить
Найдите источник и число отброшенных записей. 
journalctl -b --no-pager | grep -i "Suppressed" | tail -5
Как исправить
Снизьте подробность вывода службы. Если поток ошибок — это и есть сбой, разбирайтесь с ним: поднимать предел для маскировки не нужно.
2. Предел мал для нормальной работы службы
Почему происходит
Некоторые службы штатно пишут много: прокси, брандмауэры, почта. Для них предел по умолчанию тесен.
Как проверить
Посмотрите действующий предел. 
systemd-analyze cat-config systemd/journald.conf | grep -iE "RateLimit"
Как исправить
Поднимите предел для всей системы или отключите его для конкретной службы параметром LogRateLimitIntervalSec=0 в её unit-файле. 
[Service]
LogRateLimitIntervalSec=0
3. Разбор ведётся по неполному журналу
Почему происходит
Главная опасность не в потере записей, а в неверных выводах: искомой строки может не быть просто потому, что её отбросили.
Как проверить
Проверьте, были ли отбросы в интересующий промежуток. 
journalctl --since "10:00" --until "10:05" --no-pager | grep -i suppressed
Как исправить
При отбросах в нужном промежутке снимайте вывод службы отдельно, минуя журнал, и повторяйте наблюдение.

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

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

systemd-journald[300]: Suppressed 3894 messages from myapp.service
myapp[1200]: error: connection refused
systemd-journald[300]: Suppressed 4102 messages from myapp.service

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

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

Источники

  • journald.conf(5)
    Ограничение частоты записей.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • systemd.exec(5)
    Пределы частоты для отдельной службы.     официальная документация, systemd 255
    сверено 15 сентября 2026
  • Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
    Воспроизведено службой, пишущей тысячи строк в секунду.     собственная проверка, systemd 255
    сверено 15 сентября 2026