Служба останавливается сама: StopWhenUnneeded
Параметр StopWhenUnneeded=yes останавливает службу, когда ни один активный unit её больше не требует. Это удобно для вспомогательных служб, но неожиданно, если параметр попал в unit-файл случайно.
Вероятные причины
По порядку: сверху то, что встречается чаще.
-
Параметр задан у службы, которая должна работать постоянно
Служба, запущенная вручную, остановится как только выполнится последнее задание, которому она была нужна.
-
Служба привязана через BindsTo к unit, который остановился
Жёсткая привязка останавливает службу вместе с тем, к чему она привязана — например с устройством или точкой монтирования.
Диагностика
Команды идут в том порядке, в котором их стоит выполнять: каждая следующая проверяет то, что осталось после предыдущей.
Три параметра, из-за которых служба может остановиться сама.
systemctl show myapp.service -p StopWhenUnneeded -p BindsTo -p PartOfМомент остановки и что было рядом.
journalctl -u myapp.service -n 30 --no-pager | grep -iE "stopped|stopping"Решение
Решение своё для каждой причины. Сначала определите, какая из них ваша, — иначе правки наложатся друг на друга.
- Почему происходит
- Служба, запущенная вручную, остановится как только выполнится последнее задание, которому она была нужна.
- Как проверить
-
Посмотрите параметр и обратные зависимости.
systemctl show myapp.service -p StopWhenUnneeded systemctl list-dependencies --reverse myapp.service --no-pager | head
- Как исправить
- Уберите параметр и включите службу в автозапуск: тогда её будет требовать цель.
- Почему происходит
- Жёсткая привязка останавливает службу вместе с тем, к чему она привязана — например с устройством или точкой монтирования.
- Как проверить
-
Посмотрите привязки.
systemctl show myapp.service -p BindsTo -p PartOf
- Как исправить
- Замените привязку на обычную зависимость, если остановка вместе с ней не нужна.
Пример вывода
Служба остановилась, когда её перестали требовать. Пример показательный: он собран на тестовой машине специально для этой страницы, а не взят из чужого журнала.
systemd[1]: Stopped target myapp-stack.target.
systemd[1]: helper.service: Unit is unneeded, stopping.
systemd[1]: Stopped helper.service - Вспомогательная служба.Связанные ошибки
- Dependency failed for … и результат 'dependency' Сообщение Dependency failed for: служба не запускалась, потому что упала её зависимость. Как найти настоящего виновника.
- signal=TERM (status=15/TERM) в systemd Процесс службы завершён сигналом TERM. Когда это нормальная остановка, а когда признак проблемы.
- Connection refused в журнале службы Соединение отклонено: служба не может подключиться к базе, кешу или другому сервису. Порядок запуска, адрес, брандмауэр.
- Docker: демон не запускается без containerd docker.service падает, потому что не работает containerd.service. Разбор зависимости и сокета containerd.
- Found ordering cycle: циклическая зависимость при загрузке systemd нашёл цикл в порядке запуска и разорвал его, отбросив одну зависимость. Как найти цикл и правильно расставить After и Requires.
- Operation refused, unit may be requested by dependency only systemd отказывается запускать unit вручную из-за RefuseManualStart=yes. Что это значит и как запустить службу правильно.
- Transaction for … is destructive systemd отказывается выполнить операцию: она остановила бы что-то нужное. Разбор и безопасные варианты.
- Две службы конфликтуют: Conflicts= и взаимная остановка Запуск одной службы останавливает другую: параметр Conflicts=. Когда это полезно и когда мешает.
Источники
-
systemd.unit(5)
StopWhenUnneeded=, BindsTo=, PartOf=. -
Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)
Проверено на вспомогательной службе с этим параметром.