In some multi-user environments part of the boot-up process can come from the network. For this case systemd defaults to waiting for the network to come on-line before certain steps are taken.
Majority of Desktop Users
Unlike some multi-user environments most Ubuntu desktop users have the Operating System and drivers on their hard disks, SSDs or Live Boot USBs.
There is a glitch where some users wait an extremely long time for network to come up during boot. In this case the recommendations is to set the maximum wait time to 30 seconds. A better way is to simply disable the service at boot time.
For many users 10 to 15 seconds can be sliced off the parallel boot time by using:
It appears that this service simply waits, doing absolutely nothing, until the network is connected, and when this happens, it changes its state so that other services that depend on the network can be launched to start doing their thing.
So, it appears that this service is absolutely benign, it does not waste any time during boot, and it actually constitutes an optimization, so you are only going to make things worse if you disable it.
(Services that need the network will start before the network is up, at a time when many other services are also starting up and contention is high, and these services will be unable to do anything useful, so they will just keep retrying to connect to the network, until the network finally comes up.)
systemd-networkd-wait-online.service, systemd-networkd-wait-online - Wait for network to come online
DESCRIPTION
systemd-networkd-wait-online is a oneshot system service (see systemd.service(5)), that waits for the network to be configured. By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to be online. Here, online means that the link's operational state is equal or higher than "degraded". The threshold can be configured by --operational-state= option.
For me this is the case because my Cisco switch wasn't configured spanning-tree portfast on the interface my workstation connects to the switch on. For whatever reason the switch takes a long time to bring up the interface if portfast is not configured.
You wouldn't want to enable portfast on a switch interface that has more than one downstream computers connected to it - probably results in only one computer having connectivity. But then again if you have multiple downstream computers connected to the switch interface (via a switch for example) then you wouldn't see this behavior in the first place.
Some code runs off the network
In some multi-user environments part of the boot-up process can come from the network. For this case
systemd
defaults to waiting for the network to come on-line before certain steps are taken.Majority of Desktop Users
Unlike some multi-user environments most Ubuntu desktop users have the Operating System and drivers on their hard disks, SSDs or Live Boot USBs.
There is a glitch where some users wait an extremely long time for network to come up during boot. In this case the recommendations is to set the maximum wait time to 30 seconds. A better way is to simply disable the service at boot time.
For many users 10 to 15 seconds can be sliced off the parallel boot time by using:
After you sign on you will likely get a message bubble stating you've now been connected to the network (WiFi or Ethernet access to Internet).
It appears that this service simply waits, doing absolutely nothing, until the network is connected, and when this happens, it changes its state so that other services that depend on the network can be launched to start doing their thing.
So, it appears that this service is absolutely benign, it does not waste any time during boot, and it actually constitutes an optimization, so you are only going to make things worse if you disable it.
(Services that need the network will start before the network is up, at a time when many other services are also starting up and contention is high, and these services will be unable to do anything useful, so they will just keep retrying to connect to the network, until the network finally comes up.)
From the
man
page:For me this is the case because my Cisco switch wasn't configured
spanning-tree portfast
on the interface my workstation connects to the switch on. For whatever reason the switch takes a long time to bring up the interface ifportfast
is not configured.You wouldn't want to enable
portfast
on a switch interface that has more than one downstream computers connected to it - probably results in only one computer having connectivity. But then again if you have multiple downstream computers connected to the switch interface (via a switch for example) then you wouldn't see this behavior in the first place.