167

i just installed ubuntu server on my laptop and everything works fine except for the fact that at boot if the laptop is not connected to ethernet or in range of my wi-fi i get this message "A start job is running for wait for network to be configured" that stays for about 2 minutes. I looked up online for solutions and i tried to:

  • Disable network manager
  • Edit timeout settings in /etc/systemd/system.conf
  • Disable systemd.networkd-wait-online.service

None of these solutions worked for me. Any possible fixes?

Improve this question
6
  • Those are the fixes. After each change, did you reload NM/systemd? They only read their config files at start.
    – user535733
    Nov 2, 2017 at 17:55
  • Yes i used systemctl daemon-reload, still the same result
    – vlad27
    Nov 2, 2017 at 18:23
  • 1
    Really obscure problem! I fixed it using the @user914826's answer as well, but using the file /etc/netplan/00-installer-config.yaml.
    – aderchox
    Nov 20, 2021 at 15:29
  • @aderchox what should I do in the file /etc/netplan/00-installer-config.yaml
    – Bennison J
    Oct 6, 2023 at 14:02
  • I solved this by NOT having optional: true in my 00-installer-config.yaml due to bug bugs.launchpad.net/ubuntu/+source/systemd/+bug/2036358 - but I still have ignore-carrier: true.
    – activout.se
    Nov 19, 2023 at 13:41

8 Answers 8

Reset to default
177

Don't mask or disable the systemd service.

Edit /etc/netplan/01-netcfg.yaml and add optional: true to any devices that may not always be available.

sudo netplan apply

NOTE: setting all interfaces as optional: true will not work. It will still default to waiting for 120 seconds. Do not mark the ones required for boot (e.g. the one connected to your Wifi or Ethernet network).

Improve this answer
10
  • 10
    In what way is this superior to disabling the systemd service?
    – Andreas Hartmann
    Aug 16, 2019 at 13:42
  • 4
    For me with Ubuntu 18.04 on Vmware, the corresponding file was /etc/netplan/50-cloud-init.yaml; adding optional: true & reboot worked! Related thread: askubuntu.com/questions/1090631/…. Related info on netplan: linux.com/learn/intro-to-linux/2018/9/… (Configuring DHCP)
    – Snidhi Sofpro
    Aug 21, 2019 at 7:29
  • 3
    This worked, but I don't understand why. The "optional: true" setting indicates that the device is "not required for booting". But what if it is? Isn't this going to create other issues when another step during the boot process needs an internet connection for example? I only have 1 interface (eth0, connected to the internet) which should always be present. Why would it need 2 minutes to "become available"? What is it waiting for?
    – mae
    Apr 15, 2020 at 11:22
  • 4
    it's not workin for me in ubuntu 20.04 in virtualbox
    – Jastria Rahmat
    Aug 31, 2020 at 1:27
  • 13
    20.04 ubuntu server, I edited the file called /etc/netplan/00-installer-config.yaml
    – user128048
    Oct 28, 2021 at 7:27
88

Use 

systemctl disable systemd-networkd-wait-online.service

to disable the wait-online service to prevent the system from waiting on a network connection, and use 

systemctl mask systemd-networkd-wait-online.service

to prevent the service from starting if requested by another service (the service is symlinked to /dev/null).

Improve this answer
7
  • 1
    What means masking in this context?.
    – Jaime Hablutzel
    Mar 27, 2018 at 3:37
  • 1
    It worked. :) Can you please describe what we have done here? I am just curious.
    – Saurin Dashadia
    Apr 14, 2018 at 5:22
  • 6
    @SD @jaime-hablutzel See askubuntu.com/a/816378/445084 for an explanation of systemctl mask. Long story short: masking a service redirects it to /dev/null, preventing it from being re-enabled in the case that it is required by another service.
    – timelmer
    Apr 18, 2018 at 22:43
  • 1
    I was following advice elsewhere to just disable the service, but it kept getting re-enabled. Masking it (and NetworkManager-wait-online.service) seems to have done the trick.
    – Ketil Malde
    Feb 19, 2020 at 11:46
  • You saved my life. It worked
    – igorkf
    May 29, 2020 at 13:44
25

This means systemd-networkd-wait-online.service is hanging. There's a few known bugs with it. Check what services want network-online.target with:

systemctl show -p WantedBy network-online.target

You can disable those services if you want. Otherwise, you may have to mask the service as Mr.Ecco indicated.

Improve this answer
22

Masking systemd-networkd-wait-online.service, as suggested in other answers, may help in simple setups but it does not fix the problem. If you mask the service then all other services depending on it will also fail. That means, all services needed to wait until the network is online will fail.

I run into this problem because I use a dynamic fail-over setup for my devices with bonding the wired (e.g. enp9s0) and wireless (e.g. wlp12s0) interface that are used as slaves for the main interface bond0. Exactly the same situation do you have if you use a bridge (br0 with slave interfaces). Only the main interfaces bond0 or br0 will get online but not the slaves so systemd-networkd-wait-online.service will fail on the slaves.

The solution to this problem is to modify the service and ignore the interfaces that are slaves and does not signal to be online. You will find with:

~$ 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

The program systemd-networkd-wait-online has a parameter to ignore specific interfaces. Check with /lib/systemd/systemd-networkd-wait-online --help. So I make a drop in file to modify the service and ignore the slave interfaces:

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

In the empty editor insert these statements, of course with your interface names, save them an quit the editor:

[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online --ignore=enp9s0 --ignore=wlp12s0 --quiet

The empty ExecStart= is important because it disables the "old" command. You can check for more than one interface (look at the help).

Improve this answer
6
  • 1
    Excellent, very good answer, that was exactly my problem
    – kaklon
    Sep 13, 2019 at 10:40
  • 4
    isnt this same end result as using optional: true in netplan config?
    – yurtesen
    May 11, 2020 at 21:24
  • If the file doesn't exist use --force. systemctl edit --force systememd-networkd-wait-online.service
    – linux64kb
    May 17, 2020 at 8:56
  • @linux64kb The option --force is not needed. The drop in file is always created. That's the reason why the editor is empty. The option does not have any impact.
    – Ingo
    May 17, 2020 at 9:29
  • @linux64kb please fix systemed
    – Thiago Conrado
    Sep 2, 2020 at 3:02
4

This may not work for everyone, but it worked for me in Ubuntu 18.04 and Ubuntu 20.04.

I use SLAAC for IPv6 IP addresses, but I had dhcp6: yes in my /etc/netplan/01.netplan.yaml file and experienced the 2-minute delay on boot. I changed it to dhcp6: no and the 2-minute wait disappeared, but I still get my SLAAC IP address.

I don't completely understand why. Someone in the future may edit this answer to explain (or confirm?). I believe Netplan is trying to use DHCPv6 to get the IPv6 address and it takes a long time (2 minutes?) to fail before giving up.

Improve this answer
4

This is an oldie that appears to be resurfacing in 20.10.

Along the same lines as the previous answer, what worked here is adding link-local: [ ] to every interface in /etc/netplan/*.yaml. This overrides the default value of [ ipv6 ] (see man 5 netplan).

Then apply the change (sudo netplan apply), and networkctl -a should show the state of the interfaces as configured rather than configuring. Also, systemctl start systemd-networkd-wait-online returns immediately with success.

This is on a system with disabled IPv6 stack (ipv6.disable_ipv6=1 on the kernel commandline), so the bug appears to be that systemd-networkd-wait-online is waiting in vain for a link-local IPv6 interface to be configured.

Improve this answer
2
  • 1
    fwiw I tried setting link-local: [ ] as well as dhcpv6: false for all my interfaces, and this did not work for me. I suppose that is not enough if I do not also disable IPv6 elsewhere.
    – algal
    Mar 25, 2021 at 19:08
  • What would be the setup for ipv4?
    – Déjà vu
    Feb 23 at 14:09
3

I have a machine with 5 Ethernet ports and besides the first one I used the other four sporadically.

Assigned static IPs to the ones I used more often and added "optional: true" on all others. The boot up does not hang and wait only 2~3 seconds for configuring network services.

Improve this answer
1

in my case the offending service were related to ISCSI, and I solved it masking the services as follows:

systemctl mask open-iscsi.service iscsid.service iscsid.socket

This solution works if you don't need to use the services, otherwise you need a working configuration for your ISCSI

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .