Зависимости и упорядочение

Директивы зависимостей (Wants, Requires) отвечают на вопрос “должен ли этот юнит быть активным?” Директивы упорядочения (After, Before) — “какой юнит стартует первым?” Они полностью ортогональны.

Можно иметь упорядочение без зависимости: After=network.target означает “запустить после достижения сетевого target”, но если network.target завершится с ошибкой, твой сервис всё равно попытается стартовать. Можно иметь зависимость без упорядочения: Requires=postgresql.service означает “если postgres неактивен — завершиться с ошибкой”, но без After=postgresql.service systemd может попытаться запустить оба одновременно (параллельная активация).

На практике почти всегда нужны оба:

[Unit]
# Зависимость: если postgres не запущен, этот сервис не может работать
Requires=postgresql.service
# Упорядочение: запустить этот сервис ПОСЛЕ активации postgres
After=postgresql.service

Пропуск After= при наличии Requires= — это состояние гонки, которое бьёт чаще всего: оба сервиса стартуют параллельно, твой сервис подключается до того как postgres начал слушать, и падает — хотя зависимость технически объявлена.

Wants= vs Requires= — это про устойчивость к сбоям. Это важнейшее различие в системе зависимостей:

Wants= подходит для необязательных зависимостей — экспортёр метрик, который работает лучше с Redis, но деградирует корректно без него. Requires= — для жёстких зависимостей — сервис, который вообще не может работать без базы данных. BindsTo= — для тесно связанных пар, например сервис и сопутствующий юнит сетевого пространства имён.

[Unit]
# Мягкая зависимость: попробовать запустить redis, но продолжить даже при сбое
Wants=redis.service
After=redis.service

# Жёсткая зависимость: если postgres падает — остановить этот сервис тоже
Requires=postgresql.service
After=postgresql.service

After= и Before= управляют упорядочением в параллельной активации. По умолчанию systemd запускает юниты параллельно — граф зависимостей разворачивается, и всё, чьи зависимости удовлетворены, стартует одновременно. After= вносит ограничение последовательности:

[Unit]
# Не стартовать пока не достигнут network-online.target
After=network-online.target
# Гарантировать что этот сервис останавливается до отключения сети (при завершении)
Before=network.target

network.target vs network-online.target — распространённая ловушка: network.target достигается в момент старта сетевого менеджера — почти мгновенно. network-online.target достигается когда сеть маршрутизируема — DNS резолвится, есть маршрут по умолчанию. Сервис, делающий исходящие соединения, нуждается в After=network-online.target, а не в After=network.target.

# Посмотреть от чего реально зависит network-online.target
systemctl list-dependencies network-online.target

WantedBy= в [Install] — это то, на что воздействует systemctl enable. Он не создаёт зависимость от твоего сервиса к target — он создаёт её в обратном направлении: когда запускается systemctl enable myapp.service, создаётся симлинк в /etc/systemd/system/multi-user.target.wants/myapp.service. Когда systemd активирует multi-user.target при загрузке, он читает эту директорию wants/ и запускает всё в ней.

[Install]
WantedBy=multi-user.target

Вот почему секция [Install] не имеет эффекта до выполнения systemctl enable. Секция описывает как установить юнит, а не живую зависимость. multi-user.target — правильный выбор для любого сервиса, который должен работать в обычной (неграфической, сетевой) системе. Для сервисов, которые имеют смысл только с GUI, используй graphical.target.

# Посмотреть что multi-user.target будет запускать (после включения твоего сервиса)
ls /etc/systemd/system/multi-user.target.wants/

Как target подтягивает свои зависимости — и почему это важно для твоих собственных target’ов. Target — просто именованная точка синхронизации. Когда systemd активирует multi-user.target, он:

1. Читает директивы Wants= и Requires= (статические, в unit-файле)
2. Читает drop-in директории wants/ и requires/ (динамические, заполняемые systemctl enable)
3. Запускает все найденные юниты, соблюдая их ограничения After=

# Посмотреть полное дерево зависимостей для multi-user.target
systemctl list-dependencies multi-user.target

# Только юниты, напрямую wanted этим target'ом
systemctl list-dependencies --plain multi-user.target | head -20

Понимание этой цепочки — target → директория wants → твой сервис — делает systemctl enable менее магическим. Enable просто добавляет симлинк в директорию, которую systemd уже читает.