Сервис пропущен без ошибки: Condition и Assert в systemd

Оператор запускает службу, но приложение не появляется, а привычного failed нет. В журнале обнаруживается сообщение о невыполненном условии. Для systemd отсутствие необязательного ресурса и нарушение обязательного требования могут быть разными исходами. Это различие важно и для диагностики, и для системы уведомлений.

Посмотреть результат проверки

systemctl status report.service
systemctl show report.service -p ActiveState -p SubState -p ConditionResult -p AssertResult
systemctl cat report.service
journalctl -u report.service -b --no-pager

Найдите строки Condition и Assert в секции Unit, включая drop-in. Например, ConditionPathExists=/etc/report/enabled при отсутствии файла приводит к пропуску старта. Это может быть осознанный способ выключить необязательный компонент. Программа ещё не запускалась, поэтому искать её собственную ошибку инициализации бессмысленно.

Assert выражает требование жёстче: при провале система фиксирует ошибку стартовой операции. Но не стоит механически считать это эквивалентом падения процесса с ненулевым кодом: результат job и состояние unit требуют отдельного просмотра. Точная семантика приведена в systemd.unit.

Выбрать смысл условия

[Unit]
Description=Generate local report
ConditionPathExists=/etc/report/enabled
AssertPathExists=/etc/report/report.conf

В таком примере отсутствие enabled означает, что компонент не нужен на этом узле. Если компонент включён, отсутствие report.conf — ошибка конфигурации, которую следует показать оператору. Наличие файла не подтверждает правильность его содержимого: валидировать формат должен отдельный шаг или приложение.

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

Разобрать конкретную попытку

Предположим, ActiveState=inactive, ConditionResult=no, AssertResult=yes. Сначала устраните или подтвердите осознанный пропуск Condition. Значение AssertResult в этом снимке не доказывает пригодность всей конфигурации приложения: нужная проверка могла не выполняться в ожидаемой вами попытке. Сопоставляйте свойства со временем и сообщениями журнала.

Если файл enabled появился после неудачной попытки, сам по себе он не обязан запускать службу. Выполните новую стартовую операцию или настройте отдельный инициатор, если автоматический старт при появлении файла действительно нужен. Проверьте состояние и журнал снова, получив новую наблюдаемую попытку.

Проверить мониторинг

На стенде пройдите три состояния: компонент выключен, включён без обязательного конфига, включён с корректной конфигурацией. Уведомления должны различать ожидаемую неактивность и поломку. Проверка только systemctl is-failed может пропустить нежелательную неактивность; система наблюдения должна знать, какие службы обязаны работать на этом узле.

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

Откройте программу Linux и Bash для DevOps-инженеров. Работа с systemd и журналами помогает разбирать этапы запуска учебного сервиса и выбирать проверки, соответствующие реальной обязательности ресурсов.

Ещё по теме

• Плохой конфиг не должен запускать сервис: добавляем ExecStartPre
• В терминале лимит высокий, у службы низкий: настраиваем LimitNOFILE