Debian/Ubuntu: как убрать задержки загрузки из-за network-online, DNS и NFS в systemd

Инструкции
13 янв, 2026
Время на чтение: ~14 мин
Автор: AI (GPT 5)

Искусственный интеллект

Данная статья была создана с использованием искусственного интеллекта (GTP-5). Пожалуйста, имейте в виду, что текст может содержать неточности или ошибки.

На Debian/Ubuntu под systemd «долгая загрузка» часто выглядит одинаково: ОС уже почти поднялась, но кто-то блокирует критический путь — ожиданием network-online.target, таймаутами DNS (внутри приложений) или монтированием удалённого ресурса (чаще NFS). Итог — сервисы стартуют позже, ssh появляется не сразу, а иногда загрузка визуально «замирает» до таймаута.

Ниже — практичный разбор, как быстро найти виновника и что именно чинить: network-online.target (и wait-online сервисы), DNS (systemd-resolved / resolv.conf / NSS) и NFS (mount units и зависания при недоступности сервера).

Как измерить boot performance и найти узкое место

Начинаем с трёх команд: общая оценка, список «долгоиграющих» юнитов и цепочка критического пути. Работайте в таком порядке: сначала critical-chain (причинно-следственная связь), потом уже списки из blame.

1) Общая сводка

systemd-analyze

Смотрите, какая часть тормозит: firmware/loader/kernel/userspace. Если львиная доля — userspace, почти всегда виноваты ожидания зависимостей (сеть/remote-fs/DNS в приложениях).

2) Кто реально «долго стартует»

systemd-analyze blame

В топе часто всплывают:

systemd-networkd-wait-online.service
NetworkManager-wait-online.service
remote-fs.target и связанные *.mount (NFS/CIFS)

Важно: systemd-analyze blame показывает длительность запуска юнита, но не доказывает, что именно он блокировал загрузку. Поэтому следующий шаг обязателен.

3) Critical chain: кто блокирует загрузку

systemd-analyze critical-chain

Это ключ к пониманию: какой юнит стоит на критическом пути до default.target (или graphical.target/multi-user.target) и кто кого ждёт.

Полезно: посмотреть обратные зависимости

Чтобы понять, почему вообще кто-то «попросил» ожидание, удобно посмотреть обратные зависимости:

systemctl list-dependencies --reverse network-online.target
systemctl list-dependencies --reverse remote-fs.target

Так быстро видно «кто потребовал ожидание» и где править (обычно — не в глобальной сети, а в конкретном сервисе).

network-online.target: что это на самом деле и почему он тормозит

network-online.target — это не «сеть поднялась», а «кто-то гарантировал, что сеть считается online». Обычно это достигается ожиданием отдельного сервиса wait-online: либо от systemd-networkd, либо от NetworkManager.

Частая причина задержек — завышенные ожидания: сервисы требуют network-online.target, хотя им достаточно network.target или они могут стартовать без сети и пережить временную недоступность через ретраи.

Как понять, кто ждёт online

systemctl list-dependencies --reverse network-online.target

Если там ваш веб-сервис, воркер, агент мониторинга или планировщик — проверьте, действительно ли ему нужно «онлайн прямо сейчас», или достаточно поднять сетевой стек.

systemd-networkd-wait-online: типовые проблемы и диагностика

На хостах с systemd-networkd задержку обычно даёт systemd-networkd-wait-online.service. Он ждёт «готовности» интерфейсов по своей логике (carrier/address/routing) и может упереться в DHCP, VLAN, виртуальные интерфейсы, неиспользуемый второй NIC или нестабильный линк.

systemctl status systemd-networkd-wait-online.service
journalctl -b -u systemd-networkd-wait-online.service

Если логи показывают ожидание интерфейса, который вам не нужен для загрузки, обычно проще убрать зависимость у конкретного сервиса, чем пытаться «идеально» настроить ожидание для всех сценариев.

NetworkManager-wait-online: когда «connected» не наступает

На Ubuntu (и части Debian-десктопов) чаще встречается NetworkManager-wait-online.service. Он ждёт состояние «connected» у NetworkManager и иногда не считает сеть готовой из-за Wi‑Fi, VPN-профилей, «неуправляемых» интерфейсов, политики автоподключения или специфики маршрутов.

systemctl status NetworkManager-wait-online.service
journalctl -b -u NetworkManager-wait-online.service

Проверка сервисов, которые тянут network-online.target через systemctl

Что делать: три безопасных сценария

Сервису не нужен «online», нужен лишь сетевой стек. Переведите зависимость с network-online.target на network.target (или уберите жёсткое ожидание), чтобы не блокировать boot.

Делайте это через drop-in override, не правя пакетные unit-файлы:
```
systemctl edit your-service.service
```
Пример содержимого override:
```
[Unit]
Wants=network.target
After=network.target
```
Если в исходном юните было After=network-online.target и Wants=network-online.target, замените их на network.target. Затем:
```
systemctl daemon-reload
systemctl restart your-service.service
```
Сервису действительно нужен интернет или маршрут по умолчанию. Тогда оставляйте network-online.target, но снижайте ожидания и проверяйте, что wait-online не ждёт лишние интерфейсы.
Нужен максимально быстрый boot, а сервис может подождать сам. Уберите зависимость и обеспечьте устойчивый старт приложения: корректные таймауты подключения, ретраи, backoff; на стороне systemd — разумные Restart=on-failure и RestartSec=.

Если вы переносите сервисы на VDS, полезно заранее проверить, какие юниты реально тянут network-online.target: на виртуалках смена DHCP/DNS и порядок интерфейсов чаще проявляются именно как «зависание на загрузке».

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

DNS boot delay: почему резолв тормозит загрузку

DNS редко «висит» как отдельный юнит. Чаще задержка проявляется косвенно: какой-то сервис на старте делает DNS-запрос (к БД по имени, к API, к NTP, к внешней зависимости), и при проблемной конфигурации резолва приложение ждёт таймауты. В critical-chain это выглядит как «долгий старт сервиса», хотя корень — DNS.

Быстрая диагностика: подтверждаем, что проблема именно в резолве

journalctl -b -u systemd-resolved.service
resolvectl status
resolvectl query example.com

Если resolvectl query выполняется заметно долго или «прыгают» DNS-серверы между перезагрузками — это почти всегда конфигурационный конфликт или недоступность одного из nameserver.

Типовые причины DNS delay на Debian/Ubuntu

Конфликт менеджеров DNS. Одновременно управляют DNS: systemd-resolved, NetworkManager, cloud-init, ручные правки /etc/resolv.conf. Итог — нестабильные nameserver или адреса, недоступные на ранней стадии загрузки.
Недоступные DNS-серверы. Часто встречается на серверах: сменили сеть/маршрут, firewall закрыл UDP/TCP 53, прописали внутренний DNS, который сам поднимается позже.
Слишком агрессивные search domains. Ошибочные домены поиска приводят к множеству попыток на каждое имя (особенно при коротких хостнеймах).
NSS и порядок источников. В /etc/nsswitch.conf строка hosts: влияет на задержки: например, когда внешние запросы идут до проверки /etc/hosts, или включены источники, которые часто таймаутятся.

Что править в первую очередь (безопасный порядок)

Проверьте, какие DNS реально используются интерфейсами: resolvectl status.
Убедитесь, что доступ к DNS разрешён сетевыми политиками (UDP 53 и при необходимости TCP 53).
Сведите «источник правды» к одному менеджеру: либо systemd-resolved, либо классический resolv.conf от NetworkManager/networkd. Конфликтующие механизмы — частый источник «магических» задержек.
Если задержки завязаны на конкретный сервис — добавьте ему разумные таймауты и ретраи, чтобы загрузка не зависела от мгновенного DNS.

Если проблемы начинаются на этапе TLS (например, сервисы валятся из-за неверного времени и невалидной цепочки), проверьте синхронизацию времени и актуальность сертификатов. Для публичных проектов удобно держать сертификаты в порядке заранее — при необходимости можно выпустить SSL-сертификат под домены и поддомены.

NFS hang: когда монтирование удалённого тома блокирует boot

Если в системе есть NFS-монты через /etc/fstab, systemd генерирует mount units, которые могут попасть в критический путь через remote-fs.target. При недоступности NFS-сервера (или сети) вы получаете классический «NFS hang»: долгие таймауты и блокировку загрузки.

Как увидеть проблему в systemd

systemd-analyze critical-chain remote-fs.target
systemctl list-dependencies remote-fs.target

Дальше найдите конкретный mount-юнит (например, mnt-data.mount) и посмотрите статус и логи:

systemctl status mnt-data.mount
journalctl -b -u mnt-data.mount

Правильная стратегия: не блокировать boot

Для большинства серверных задач правильнее сделать так, чтобы:

загрузка ОС не зависела от удалённого хранилища;
монты поднимались после появления сети и по требованию;
при недоступности NFS поведение было предсказуемым (таймауты, nofail, автомаунт).

Связь NFS и network-online.target

Частая ошибка — заставлять NFS-монтирование ждать network-online.target глобально. Это иногда ухудшает ситуацию: вы добавляете ещё одну точку блокировки загрузки, вместо того чтобы дать системе подняться и потом «догнать» монты.

Практика:

для большинства задач достаточно _netdev + x-systemd.automount + таймауты;
если конкретный сервис требует NFS строго до старта — пусть он зависит от конкретного *.mount, а не от network-online.target «в целом».

Диагностика зависаний remote-fs.target и NFS mount units в systemd

На проектах с файловыми шарами и тяжёлыми I/O иногда удобнее разделять роли: веб-часть отдельно, хранилище и фоновые задачи отдельно, чтобы сбой сети не тормозил всё сразу. Для веба в ряде случаев достаточно виртуального хостинга, а NFS и сервисы обработки — на отдельной машине.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Чеклист: быстрый путь от симптома к решению

Соберите картину: systemd-analyze, затем systemd-analyze blame, затем systemd-analyze critical-chain.
Если в топе wait-online: найдите, кто тянет network-online.target через systemctl list-dependencies --reverse network-online.target.
Точечно ослабьте зависимости сервисов до network.target, если им не нужен «online».
Если задержка проявляется внутри сервиса: проверьте DNS через resolvectl и сетевую доступность его зависимостей.
Если залипает remote-fs.target или *.mount: добавьте x-systemd.automount, nofail и таймауты в /etc/fstab.
Перепроверьте после правок: перезагрузка и повторные замеры systemd-analyze и critical-chain.

Мини-справочник команд (копипаст для дежурного инженера)

systemd-analyze
systemd-analyze blame
systemd-analyze critical-chain

systemctl list-dependencies --reverse network-online.target
systemctl list-dependencies --reverse remote-fs.target

systemctl status systemd-networkd-wait-online.service
systemctl status NetworkManager-wait-online.service

journalctl -b -u systemd-networkd-wait-online.service
journalctl -b -u NetworkManager-wait-online.service

journalctl -b -u systemd-resolved.service
resolvectl status
resolvectl query example.com

systemctl status remote-fs.target
systemd-analyze critical-chain remote-fs.target

Что учесть на новых серверах и при миграциях

На новых инстансах проблема часто проявляется «внезапно» после переезда: меняется DHCP/DNS, добавляется второй интерфейс, появляются remote-fs монты. Если вы переносите проекты на VDS, заранее проверьте сетевую схему (какой интерфейс должен стать «основным»), источники DNS и поведение NFS при недоступности — это дешевле, чем ловить таймауты в момент аварии.

И главное правило: не отключайте wait-online «наугад». Сначала найдите, кому и зачем нужен network-online.target, и ослабляйте зависимости точечно там, где это действительно безопасно.

Поделиться статьей