Служба active, приложение ещё не готово: когда нужен Type=notify

Служба получила active, следующая задача сразу обратилась к ней и встретила неготовое состояние. Сам процесс уже существует, но ещё загружает индекс. Для правильного порядка systemd должен знать прикладную границу готовности. Если приложение поддерживает уведомления, эту границу можно передать через Type=notify.

Проверить поддержку приложения

Одной строки Type=notify недостаточно. Программа должна отправить READY=1 через механизм sd_notify после завершения нужной инициализации. Многие готовые приложения имеют отдельный флаг или режим для этого. Если поддержки нет, смена типа приведёт к ожиданию и таймауту запуска, а не к автоматическому обнаружению готовности.

[Service]
Type=notify
NotifyAccess=main
ExecStart=/usr/local/bin/index-worker --systemd-notify
TimeoutStartSec=90s

index-worker и его флаг здесь обозначают приложение с документированной поддержкой; это пример конфигурации интеграции, а не универсальная команда. NotifyAccess должен соответствовать тому процессу, который действительно отправляет сообщение. Без необходимости не расширяйте доступ до all.

Определить смысл READY

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

systemctl show index-worker.service -p ActiveState -p SubState -p Result -p StatusText
journalctl -u index-worker.service -b -o short-monotonic
systemctl show report.service -p After -p Requires

При корректной интеграции сначала видно activating, затем сообщение о завершении инициализации и переход в active. Зависимый unit с подходящими After/Requires ждёт окончания стартовой операции. Но это не означает, что systemd затем проверяет пригодность каждой операции приложения: дальнейшее здоровье требует своей модели наблюдения.

Прочитать неудачный старт

Допустим, журнал показывает запуск на 4-й секунде, «loading index» на 5-й и timeout на 94-й без READY. Проверьте, был ли включён режим уведомлений, кто послал сообщение, передан ли NOTIFY_SOCKET и не завершился ли главный процесс. Увеличивать TimeoutStartSec стоит после подтверждения реальной длительности, а не вместо исправления протокола.

Обёртки, запускающие отправителя уведомления и сразу завершающиеся, могут создавать гонку атрибуции. Для собственного приложения лучше использовать поддерживаемую библиотечную интеграцию. Возможности sd_notify и правила службы описаны в systemd.service.

Проверить два сценария

На стенде сделайте инициализацию заметно долгой и убедитесь, что потребитель не стартует раньше READY. Затем вызовите ошибку обязательного ресурса: служба должна ясно завершить старт с ошибкой, а не объявить готовность и упасть через секунду. Сохраните совместный монотонный журнал.

Если приложение не поддерживает notify, используйте его штатную модель запуска и отдельную проверку готовности там, где она нужна. Фиксированный sleep хрупок при изменении объёма данных и скорости диска.

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

Ещё по теме

• Сервис пропущен без ошибки: Condition и Assert в systemd
• Плохой конфиг не должен запускать сервис: добавляем ExecStartPre