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?

  • Those are the fixes. After each change, did you reload NM/systemd? They only read their config files at start. – user535733 Nov 2 '17 at 17:55
  • Yes i used systemctl daemon-reload, still the same result – vlad27 Nov 2 '17 at 18:23

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
  • 1
    In my case it only worked after setting all interfaces to optional: true – duli Mar 4 '19 at 14:11
  • 2
    In what way is this superior to disabling the systemd service? – Andreas Hartmann Aug 16 '19 at 13:42
  • 2
    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 '19 at 7:29
  • 2
    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 '20 at 11:22
  • 2
    it's not workin for me in ubuntu 20.04 in virtualbox – Jastria Rahmat Aug 31 '20 at 1:27


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).

  • 1
    What means masking in this context?. – Jaime Hablutzel Mar 27 '18 at 3:37
  • It worked. :) Can you please describe what we have done here? I am just curious. – Saurin Dashadia Apr 14 '18 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 '18 at 22:43
  • 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 '20 at 11:46
  • You saved my life. It worked – igorkf May 29 '20 at 13:44

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.


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\]'

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:

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).

  • Excellent, very good answer, that was exactly my problem – kaklon Sep 13 '19 at 10:40
  • isnt this same end result as using optional: true in netplan config? – yurtesen May 11 '20 at 21:24
  • If the file doesn't exist use --force. systemctl edit --force systememd-networkd-wait-online.service – linux64kb May 17 '20 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 '20 at 9:29
  • @linux64kb please fix systemed – Thiago Conrado Sep 2 '20 at 3:02

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.

  • 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 at 19:08

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.


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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.