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

В журнале нет сообщений об ошибке, хотя служба падает

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

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

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

  1. Уровень записей ограничен в unit-файле

    Параметр наибольшего уровня отбрасывает записи ниже порога прямо на входе. Сообщения об ошибках могут не дойти до журнала.

  2. Вывод перенаправлен мимо журнала

    Вывод может уходить в файл или отбрасываться. Тогда журнал пуст независимо от уровней.

  3. Программа пишет не в поток, а в свой файл

    Тогда в журнале только сообщения systemd о запуске и падении, а подробности — в файле программы.

Диагностика

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

Уровень и направление вывода службы.

systemctl show myapp.service -p LogLevelMax -p StandardOutput -p StandardError

Записи уровня ошибки и выше.

journalctl -u myapp.service -p err -n 20 --no-pager

Все записи без фильтра по уровню.

journalctl -u myapp.service -n 30 --no-pager

Решение

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

1. Уровень записей ограничен в unit-файле
Почему происходит
Параметр наибольшего уровня отбрасывает записи ниже порога прямо на входе. Сообщения об ошибках могут не дойти до журнала.
Как проверить
Посмотрите параметры вывода службы.
systemctl show myapp.service -p LogLevelMax -p StandardOutput -p StandardError
Как исправить
Уберите ограничение уровня на время разбора. Ставить порог ниже уровня предупреждений на боевой машине рискованно.
2. Вывод перенаправлен мимо журнала
Почему происходит
Вывод может уходить в файл или отбрасываться. Тогда журнал пуст независимо от уровней.
Как проверить
Посмотрите, куда идёт вывод.
systemctl show myapp.service -p StandardOutput -p StandardError
Как исправить
Верните вывод в журнал на время разбора. Если вывод пишется в файл, смотрите его.
3. Программа пишет не в поток, а в свой файл
Почему происходит
Тогда в журнале только сообщения systemd о запуске и падении, а подробности — в файле программы.
Как проверить
Найдите файлы журнала программы.
systemctl cat myapp.service | grep -iE "log|Environment"
sudo ls -lt /var/log/myapp/ 2>/dev/null | head
Как исправить
Смотрите файл программы или настройте вывод в поток: тогда всё соберётся в журнале с привязкой к unit.

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

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

$ journalctl -u myapp.service -n 5 --no-pager
systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: myapp.service: Failed with result 'exit-code'.

$ systemctl show myapp.service -p LogLevelMax -p StandardError
LogLevelMax=notice
StandardError=null

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

Источники

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