В журнале нет сообщений об ошибке, хотя служба падает
Ограничение уровня записей — полезный способ убрать шум, но настроенный неудачно он скрывает ровно то, что нужно при разборе сбоя. Если служба падает без следов в журнале, стоит проверить именно это, прежде чем искать причину в самой программе.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Уровень записей ограничен в unit-файле
Параметр наибольшего уровня отбрасывает записи ниже порога прямо на входе. Сообщения об ошибках могут не дойти до журнала.
-
Вывод перенаправлен мимо журнала
Вывод может уходить в файл или отбрасываться. Тогда журнал пуст независимо от уровней.
-
Программа пишет не в поток, а в свой файл
Тогда в журнале только сообщения 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Решение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Параметр наибольшего уровня отбрасывает записи ниже порога прямо на входе. Сообщения об ошибках могут не дойти до журнала.
- Как проверить
-
Посмотрите параметры вывода службы.
systemctl show myapp.service -p LogLevelMax -p StandardOutput -p StandardError
- Как исправить
- Уберите ограничение уровня на время разбора. Ставить порог ниже уровня предупреждений на боевой машине рискованно.
- Почему происходит
- Вывод может уходить в файл или отбрасываться. Тогда журнал пуст независимо от уровней.
- Как проверить
-
Посмотрите, куда идёт вывод.
systemctl show myapp.service -p StandardOutput -p StandardError
- Как исправить
- Верните вывод в журнал на время разбора. Если вывод пишется в файл, смотрите его.
- Почему происходит
- Тогда в журнале только сообщения 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
Связанные ошибки
- Журнал службы пуст, хотя приложение работает Вывод приложения не появляется в журнале: буферизация вывода при перенаправлении в канал.
- status=1/FAILURE в systemd Код 1/FAILURE означает, что программа запустилась и сама завершилась с ошибкой. Как найти настоящую причину в журнале службы.
- Suppressed N messages from unit: часть записей потеряна journald отбросил часть записей из-за ограничения частоты. Как понять, что именно потеряно, и когда предел нужно поднять.
- Журнал пропадает после перезагрузки journalctl не показывает записи прошлых загрузок: журнал хранится только в памяти. Как включить постоянное хранение.
- Failed to start … — что делать с общим сообщением Строка Failed to start сообщает только факт. Порядок разбора: найти настоящую причину выше по журналу.
- File corrupted or uncleanly shut down, renaming and replacing Журнал повреждён после жёсткой перезагрузки: что означает сообщение и когда нужно вмешательство.
- Invalid argument в журнале службы Ошибка 22: недопустимый аргумент системного вызова. Как сузить поиск, когда сообщение ничего не уточняет.
- Job for myapp.service failed: с чего начинать разбор Сообщение systemctl при неудачном запуске: что в нём есть, чего в нём нет и какие три команды дают ответ.
Источники
-
systemd.exec(5)
Параметры уровня и направления вывода. -
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Воспроизведено ограничением уровня записей у службы.