systemd-networkd-wait-online[299]: Timeout occurred while waiting for network connectivity.

systemctl disable

Это выключает автозапуск сервиса. Его по-прежнему можно запускать руками. Если ты точно уверен, что тебе надо запретить запуск, это делается командой mask. Но лучше разобраться с проблемой, а не заклеивать пластырем.

enabled-runtime

Сервис включил другой юнит для текущей загрузки.

systemctl edit systemd-networkd-wait-online.service - все закомментировано.

Так и должно быть, оно же для внесения изменений.

systemctl --force --full edit systemd-networkd-wait-online.service

Как вообще отключить эту фигню (ожидание сети при загрузке)?

Лучше починить. Посмотри, от чего у тебя зависит network-online.target. Должна от того сервиса, который на самом деле настраивает сеть.

Надо дизейблить не только юнит, но и сокет, в systemd же еще и сокет-активация есть. Когда сервис включен, он будет запускаться автоматом, но если он выключен – никто не мешает запустить его через сокет. Вот если и сокет выключен, это будет равносильно mask сервис, по идее.

Установи devuan там нету системг.

Установи devuan там нету системг.

Лень, если вообще возможно. Это Апельсинка, предпочитаю юзать готовые образы.

Короче лень разбираться в этих ваших юнитах.

ExecStart=/bin/false - и нет проблем.

это будет равносильно mask сервис, по идее

Нет. Он всё ещё может быть запущен по зависимости или вручную. mask делает запуск невозможным.

systemctl edit systemd-networkd-wait-online.service - все закомментировано.

A systemctl cat systemd-networkd-wait-online.service?

Проблема не в самом сервисе systemd-networkd-wait-online.service. Этот сервис тянет таргет network-online.target. Проблема в сервисах, которые тянут network-online.target. Хорошему сервису должно быть положить на состояние сети, он должен запускаться независимо от сетевой связности, и не зависеть от network-online.target. Но не все сервисы «хорошие». Посмотри, какие сервисы тянут network-online.target, вот они и виновны в этом ожидании сети при загрузке. systemctl list-dependencies --reverse network-online.target.

Например, в моём centos9 rsyslog.service почему-то имеет зависимость на network-online.target, хотя у процесса rsyslog нет даже сетевых сокетов (только UNIX сокеты). Я убрал у него зависимость на network-online.target c помощью systemctl edit --full rsyslog.service.

Ещё у меня сервис rpc-statd-notify.service тянет зависимость от network-online.target. Это видимо пример «плохого» сервиса. Он при загрузке должен уведомлять NFS серверы о том, что NFS клиент перезагрузился, и все его локи на сервере (взятые до ребута) можно отпустить. Мне это не нужно, я его замаскировал.

https://systemd.io/NETWORK_ONLINE/ тут объяснение, что это за костыль вообще такой, network-online.target.

Раньше он ждал бесконечно настройки сети.

Я вижу два пути решения.

Первый: отредактировать (systemctl edit) юнит и добавить в ExecStart ключ -i основной_сетевой_интерфейс. В этом случае systemd-networkd-wait-online будет ждать настройки только этого интерфейса.

Второй: проинспектировать настройки в /etc/systemd/network. В юнитах как-то указывается, нужно ли ждать настройки интерфейса. Это надо в доках смотреть. Я так с разбегу не скажу, что именно надо прописать.

UPD: https://www.freedesktop.org/software/systemd/man/latest/systemd.network.html#...

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

эту фигню было потом видно в dmesg. Снёс этот пакет и всё заработало

UPD. connman чего-то там по моему так назывался

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

nginx.

Удивлен. Потому что на других дистрах такого не наблюдал, видимо криворукие мейтейнеры этого Дебиана\Армбиана.

В Дженту так у nginx

depend() {
        need net
        use dns logger netmount
}

Нет, я удивлен не тому что nginx'у нужна сеть, а тому что мейтейнер криво расставил таймауты (совсем как при выключении, да).

Я не замерял точно, но ориентировочно это на пару минут.

Ладно, у какого-то дебила из группы разработчиков сетка может подниматься по dhcp две минуты...

Но неужели трудно понять, что если аплинка нет - то тупо по две минуты ждать поднятия сети, потому что скорее всего это аппаратная проблема?

Это первый момент ... И второй момент, который не нравится многим и мне в том числе: какое дело инициализатору до моей сети? Не нравится nginx'у отсутствие сети - вот пусть сам и ждет. Загрузку-то системы напуркуа тормозить?

Например, в моём centos9 rsyslog.service почему-то имеет зависимость на network-online.target, хотя у процесса rsyslog нет даже сетевых сокетов (только UNIX сокеты).

Он может отправлять/принимать логи по сети, вполне логично.

Если nginx биндится на 0.0.0.0 и ::, то ему не нужна «настроенная» сеть (что бы это ни значило). Биндиться на 0.0.0.0 и :: это его конфигурация по умолчанию. Если ты её не менял, можешь просто убрать ненужную зависимость nginx.service от network-online.target.

Такие зависимости недалёкие (а где найти других) мейнтейнеры добавляют в качестве респонза на багрепорты от недалёких пользователей.

Нет, это сугубо локальная фишка, так что да, биндится он дефолтно.

В принципе глюкан я починил по-своему, молотком, но все таки необычно иметь такой бардак в системе.