Перейти к содержанию

Ожидание сети при загрузке и сетевые зависимости служб

Многие приложения стартуют раньше, чем сеть получает маршрут, DNS или доступ к удалённому сервису. В НАЙС.ОС CLOUD за статусом интерфейсов следит systemd-networkd; ожидание сети реализуется соответствующим механизмом systemd, если он включён в конкретном профиле. Не все установки должны блокировать запуск из-за отсутствующего второстепенного порта.

1. Различайте состояния

  • network.target не гарантирует IP-адрес или DNS; это в основном точка упорядочивания сетевых служб.
  • network-online.target используется службами, которым требуется готовая сеть на старте, но её достижение зависит от активной службы ожидания и профилей networkd.
  • Даже успешный network-online.target не гарантирует доступность Интернет-ресурсов или удалённой базы данных.

2. Диагностика загрузки

systemctl status systemd-networkd --no-pager
systemctl status systemd-networkd-wait-online.service --no-pager
systemctl is-enabled systemd-networkd-wait-online.service
systemd-analyze critical-chain network-online.target
systemd-analyze blame | head -30
networkctl list
journalctl -b -u systemd-networkd -u systemd-networkd-wait-online --no-pager

Сначала прочитайте journal: зависание может быть вызвано тем, что второстепенный интерфейс без линка считается обязательным, или тем, что запрос DHCP не завершился.

3. Необязательные порты

В профиле .network можно явно задать требования к состоянию линка; конкретные параметры поддерживаются версией systemd 257, но их фактическое поведение следует проверять.

[Match]
Name=ens4

[Link]
RequiredForOnline=no

[Network]
DHCP=ipv4

Такой подход применим к интерфейсу, отсутствие которого не мешает основному назначению сервера. Не отмечайте основной uplink как необязательный только ради «быстрого зелёного статуса».

4. Сетевая зависимость собственного сервиса

Для собственного unit, которому нужна готовая сеть при первом запуске:

[Unit]
Description=Example app requiring configured network
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/my-service
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

After= задаёт порядок, а Wants= притягивает цель. Это не проверка удалённого порта; само приложение должно повторять подключения при временной недоступности зависимости. Перед созданием unit проверьте, существует ли исполняемый файл и задана ли модель прав.

5. Что делать при задержке старта

  1. systemd-analyze critical-chain — определить реальную цепочку ожидания.
  2. networkctl list — увидеть состояние обязательных интерфейсов.
  3. journalctl — прочитать причину, не интерпретировать timeout вслепую.
  4. Исправить конкретный профиль .network, конфигурацию DHCP или зависимость unit.
  5. Перезагрузку проводить только после контрольного запуска и с доступной консолью.

Источники: systemd.special, systemd.network.