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

**URL:** <https://kryptos.forum/t/sobstvennaya-sluzhba-systemd-ne-startuet-pri-zagruzke-a-posle-ruchnogo-zapuska-rabotaet-zavisimost-upala-iz-za-otsutstvuyushhej-seti-i-requires-utyanul-za-soboj/256>\
**Category:** Разработка ПО\
**Tags:** разработка\
**Created:** [30.Сентябрь.2026 10:28:08 UTC](https://kryptos.forum/t/sobstvennaya-sluzhba-systemd-ne-startuet-pri-zagruzke-a-posle-ruchnogo-zapuska-rabotaet-zavisimost-upala-iz-za-otsutstvuyushhej-seti-i-requires-utyanul-za-soboj/256 "2026-09-30T10:28:08Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![team\_dev](https://kryptos.forum/letter_avatar_proxy/v4/letter/t/ecae2f/32.png) [@team\_dev](https://kryptos.forum/u/team_dev)\
**Post date:** [30.Сентябрь.2026 10:28:08 UTC](https://kryptos.forum/t/sobstvennaya-sluzhba-systemd-ne-startuet-pri-zagruzke-a-posle-ruchnogo-zapuska-rabotaet-zavisimost-upala-iz-za-otsutstvuyushhej-seti-i-requires-utyanul-za-soboj/256/1 "2026-09-30T10:28:08Z")

</div>

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

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

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

```auto
sudo systemctl edit app.service

```

```auto
[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](https://www.freedesktop.org/software/systemd/man/latest/systemd.special.html#network-online.target).