#Что происходит и когда это важно
Загрузка задерживается, видны сообщения A start job is running... или TimeoutStartSec; после старта сети приложение иногда запускается вручную.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Служба неверно ожидает network-onlinenetwork-online.target означает завершение процедуры ожидания сети, а не доступность нужного сервера. | В журнале сетевой target достигнут, но приложение не подключается к адресу. | Проверить конкретный DNS/маршрут/службу. |
| Сетевой интерфейс не готов вовремяМенеджер сети ждёт отсутствующий интерфейс или DHCP. | systemd-analyze critical-chain показывает длительное ожидание. | Найти интерфейс и менеджер сети. |
| Другая зависимость блокирует запускСлужба ждёт каталог, диск, секрет или иной unit. | В графе зависимостей перед ней другой долгий unit. | Исследовать зависимости вместо увеличения таймаута. |
#Пошаговая диагностика и исправление
- Уточните, что именно зависаетОткройте терминал после загрузки или доступную консоль. Введите
systemctl status ИМЯ.service --no-pagerиjournalctl -u ИМЯ.service -b --no-pager. Запишите время старта и строку TimeoutStartSec или ошибку соединения; если SSH недоступен, используйте локальную консоль. - Посмотрите последовательность запускаВыполните
systemd-analyze blameиsystemd-analyze critical-chain ИМЯ.service. Первая команда перечисляет длительность активации единиц, вторая показывает критическую цепочку. Не все параллельные задержки видны в blame — сопоставьте результат с журналом. - Проверьте сетевые цели и зависимостиВыполните
systemctl cat ИМЯ.service; ищитеAfter=network-online.target,Wants=network-online.target,RequiresMountsFor=. Затемsystemctl status network-online.target --no-pager. Наличие After= без Wants= само по себе не запускает цель и не гарантирует доступность интернета. - Проверьте доступность нужного ресурсаЕсли сервис соединяется с доменом, сначала убедитесь, что интерфейс имеет адрес (
ip -br addr), затем проверьте маршрут (ip route) и разрешение именно нужного имени (getent ahosts ДОМЕН). Ошибка DNS отличается от недоступного удалённого TCP-порта; не отключайте брандмауэр ради ускорения загрузки. - Найдите реальный менеджер сетиВыполните
systemctl list-unit-files "*wait-online*"; он покажет имеющиеся службы ожидания у NetworkManager/systemd-networkd. Выясните, какая из них запускается и чего ждёт, но не выключайте её на удалённом сервере без резервного доступа. - Исправляйте точечную зависимостьЕсли подтвердили неправильное использование network-online, администратор готовит резервную копию своего unit и правит зависимости после изучения логики приложения. Если сервису нужен конкретный внешний ресурс, корректнее обеспечить повторные попытки подключения средствами самого приложения, а не просто бесконечно увеличивать TimeoutStartSec.
- Проверьте следующую загрузкуПосле согласованной правки unit выполните daemon-reload, перезагрузите машину в окно обслуживания и снова сравните журнал и critical-chain. На сервере сохраняйте резервный доступ к сети, иначе исправление может лишить соединения.
#Команды из инструкции с пояснениями
Linux · Терминал (Bash)Команда
Показывает критическую цепочку запуска службы.
systemd-analyze critical-chain ИМЯ.serviceLinux · Терминал (Bash)Команда
Просмотр времени активации unit.
systemd-analyze blameLinux · Терминал (Bash)Команда
Показывает адреса интерфейсов.
ip -br addrLinux · Терминал (Bash)Команда
Показывает маршруты IPv4.
ip route#Как проверить результат
Служба запускается при штатной загрузке без ненужного ожидания, а приложение действительно подключается к требуемому удалённому ресурсу.
#Если проблема не устранена
Если network-online завершился, но соединение не работает, проверяйте IP, DNS, доступ к конкретному адресу и ошибки приложения по отдельности. При пропадающем SSH исправления выполняйте с консоли.