LogLevelMax= в systemd: ограничение уровня записей службы
Задаёт наибольший уровень (наименьшую важность) записей, которые попадут в журнал от этой службы. Всё, что менее важно, отбрасывается сразу и в журнале не появится никогда.
Что делает
Важно понимать разницу с фильтром при чтении: journalctl -p err показывает часть уже сохранённых записей, а этот параметр не даёт им сохраниться. Отброшенное восстановить нельзя, поэтому значение ниже уровня предупреждений на боевой машине — риск остаться без сведений о сбое.
Уровни задаются именами (emerg, alert, crit, err, warning, notice, info, debug) или числами от нуля до семи. Для служб, пишущих много отладочного вывода, разумный выбор — notice или warning: шум уходит, а сообщения об ошибках остаются.
Параметр применяется к записям, пришедшим через потоки вывода и через сокет журнала. Записи, которые служба пишет в свой файл, ему не подчиняются — там уровень задаётся настройками самой программы.
Где ставится. В секции [Service] или в любой секции исполнения (сокеты, монтирования, задачи по расписанию).
Значения
| Значение | Что происходит |
|---|---|
LogLevelMax=warning | оставить предупреждения и всё более важное. |
LogLevelMax=info | убрать только отладочный поток. |
LogLevelMax=debug | не отбрасывать ничего — то же, что без параметра. |
По умолчанию: без ограничения (debug)
Пример
Служба с очень подробным отладочным выводом.
[Service]
ExecStart=/usr/local/bin/myapp
LogLevelMax=noticeОтладочные строки в журнал не попадут, а предупреждения и ошибки останутся. Для разбора сбоя параметр стоит временно убрать, а не менять фильтры чтения.
Типичные ошибки
Значение вроде crit прячет обычные ошибки службы: в журнале останется только запись systemd о падении.
Параметр не фильтр чтения: отброшенные записи не сохраняются и позже их не найти.
На вывод, который программа пишет в собственный файл, он не влияет.
При разборе сбоя проверяйте его до того, как искать причину в коде: пустой журнал часто объясняется именно им.
Связанные ошибки
- В журнале нет сообщений об ошибке, хотя служба падаетОшибки не видны: уровень подробности обрезан параметрами unit-файла или настройками журнала.
- Журнал службы пуст, хотя приложение работаетВывод приложения не появляется в журнале: буферизация вывода при перенаправлении в канал.
- Suppressed N messages from unit: часть записей потерянаjournald отбросил часть записей из-за ограничения частоты. Как понять, что именно потеряно, и когда предел нужно поднять.
Рядом стоящие параметры
Где важен на практике
Источники
- systemd.exec(5)
- journalctl(1)
- Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)