Задание запуска работает за ожиданием сети, которая будет настроена. Сервер Ubuntu 17.10

Команды использования:

$ sudo systemctl stop systemd-networkd-wait-online.service
$ sudo systemctl disable systemd-networkd-wait-online.service

Используйте

systemctl disable systemd-networkd-wait-online.service

, чтобы отключить службу ожидания в режиме онлайн, чтобы система не ожидала подключения к сети, и используйте

systemctl mask systemd-networkd-wait-online.service

, чтобы предотвратить запуск службы по запросу другим сервисом (сервис связан с /dev/null).

Это означает systemd-networkd-wait-online.service зависает. Существует несколько известных ошибок с ним. Проверьте то, что хотят сервисы network-online.target с:

systemctl show -p WantedBy network-online.target

Можно отключить те сервисы, если Вы хотите. Иначе Вам, вероятно, придется замаскировать сервис, как г-н Ecco указал.

Не маскируйте или отключайте systemd сервис.

Править /etc/netplan/01-netcfg.yaml и добавьте optional: true к любым устройствам, которые не могут всегда быть доступными.

sudo netplan apply

Маскирование systemd-networkd-wait-online.service, как предложено в других ответах, может помочь в простых установках, но это не решает проблему. При маскировании сервиса затем, все другие сервисы в зависимости от него также перестанут работать. Это означает, все сервисы должны были ожидать, пока сеть не онлайн, перестанет работать.

Я сталкиваюсь с этой проблемой, потому что я использую динамическую установку обработки отказа для своих ноутбуков со связыванием проводного (enp9s0) и беспроводная связь (wlp12s0) интерфейс, которые используются в качестве ведомых устройств для основного интерфейса bond0. Точно та же ситуация делает Вы имеете при использовании моста (br0 с ведомыми интерфейсами). Только основные интерфейсы bond0 или br0 станут онлайн, но не ведомые устройства так systemd-networkd-wait-online.service перестанет работать на ведомых устройствах.

Решение этой проблемы состоит в том, чтобы изменить сервис и проверить только на интерфейсы, которые должны пойти онлайн. Вы найдете с:

~$ sudo systemctl cat systemd-networkd-wait-online.service | grep --after-context=3 '\[Service\]'
[Service]
Type=oneshot
ExecStart=/lib/systemd/systemd-networkd-wait-online
RemainAfterExit=yes

Программа systemd-networkd-wait-online имеет параметр для тестирования определенных интерфейсов. Свериться /lib/systemd/systemd-networkd-wait-online --help. Таким образом, я делаю понижение файла для изменения сервиса:

~$ sudo systemctl edit systemd-networkd-wait-online.service

В пустом редакторе вставляют эти операторы, конечно, с Вашим интерфейсом, сохраняют их выход редактор:

[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online --interface=bond0 --quiet

Пустое ExecStart= важно, потому что это отключает "старую" команду. Можно проверить на больше, чем в интерфейсе (посмотрите на справку).

Это может работать не у всех, но у меня сработало в Ubuntu 18.04 и Ubuntu 20.04.

Я использую SLAAC для IPv6 IP-адресов, но у меня был dhcp6: yes в моем файле /etc/netplan/01.netplan.yaml и возникла 2-минутная задержка при ботинок. Я изменил его на dhcp6: no, и 2-минутное ожидание исчезло, но я все еще получаю свой IP-адрес SLAAC.

Не совсем понимаю почему. Кто-то в будущем может отредактировать этот ответ, чтобы объяснить (или подтвердить?). Я считаю, что Netplan пытается использовать DHCPv6 для получения IPv6-адреса, и требуется много времени (2 минуты?), прежде чем сдаться.

Это старая версия, которая, похоже, появится в обновлении 20.10.

По аналогии с предыдущим ответом, здесь сработало добавление link-local: [ ] к каждому интерфейсу в /etc/netplan/*.yaml . Это переопределяет значение по умолчанию [ipv6] (см. man 5 netplan).

Затем примените изменение (sudo netplan apply), и networkctl -a должно показывать состояние интерфейсов как configured, а не configuring . Кроме того, systemctl start systemd-networkd-wait-online немедленно возвращается с успехом.

Это в системе с отключенным стеком IPv6 (ipv6.disable_ipv6=1 в командной строке ядра), поэтому ошибка, похоже, заключается в том, что systemd-networkd-wait-online тщетно ждет настройки локального IPv6-интерфейса.