Собственная служба systemd не стартует при загрузке, а после ручного запуска работает: зависимость упала из-за отсутствующей сети, и Requires утянул за собой

Разработка ПО
1

Что было. Служба-обёртка app-control.service с Requires=app.service не запускается при загрузке. systemctl restart после загрузки решает вопрос до следующей перезагрузки.

Причина. Основная служба app.service при старте резолвила имя хоста и падала: Failed to resolve 'host.home.arpa': Temporary failure in name resolution. На момент её запуска сеть ещё не была настроена. Из-за Requires= зависимая служба тоже не стартовала. Участники предложили привязать основную службу к готовности сети; автор подтвердил.

Решение. Drop-in для основной службы:

sudo systemctl edit app.service

[Unit]
After=network-online.target
Wants=network-online.target

Wants вместо Requires для цели сети, чтобы служба не блокировалась навсегда, если цель по какой-то причине недостижима. Один из участников добавил nss-lookup.target (готовность резолвера) и systemd-time-wait-sync.service (синхронизированное время) для служб, чувствительных к DNS и часам. Затем systemctl daemon-reload.

Что означает network-online.target. Цель достигается, когда сетевой менеджер сообщает, что интерфейсы настроены (systemd-networkd-wait-online или NetworkManager-wait-online). Без этой зависимости служба стартует сразу после network.target, который означает лишь «сетевая подсистема запущена», а адресов и маршрутов может ещё не быть. На виртуальных машинах с DHCP это окно составляет секунды, ровно чтобы служба упала.

Ещё два предохранителя.

  1. В зависимой службе Wants=app.service вместо Requires=, если она может подождать: тогда её не роняет падение основной. Либо BindsTo=, если она без основной бессмысленна и должна останавливаться вместе с ней.
  2. В самой службе Restart=on-failure и RestartSec=5: если DNS появился через 10 секунд, вторая попытка пройдёт. Про правильную настройку лимитов перезапуска есть отдельный разбор.

Диагностика. journalctl -b -u app.service -u app-control.service (оба юнита в одной ленте), systemctl list-dependencies app-control.service, systemd-analyze critical-chain app.service (в какой момент загрузки стартовала). Если в журнале ошибки разрешения имён или «network unreachable» в первые секунды загрузки, диагноз тот же.

Про имена в конфигурации. Служба, которая ходит к другому серверу, должна уметь переживать временную недоступность DNS (повтор с задержкой). Если она не умеет, зависимость от network-online.target это минимум; жёстко прописывать адреса вместо имён хуже.

Цели systemd описаны в документации systemd.