Linux networkmanager wait online service

NAME

NetworkManager-wait-online.service - Wait for network to come online

DESCRIPTION

NetworkManager-wait-online.service delays network-online.target until network is ready. The systemd target network-online.target acts as a synchronization point for services to start after network is configured. Such services should order themselves After=network-online.target (and never After=NetworkManager-wait-online.service). NetworkManager-wait-online.service is a one-shot service that itself is ordered Before=network-online.target and this way delays the target until the network is configured. NetworkManager-wait-online.service itself is almost not configurable itself. Instead the connection profiles and configuration in NetworkManager affects the behavior. In the best case, all services on the system can react to networking changes dynamically and no service orders itself after network-online.target. That way, NetworkManager-wait-online.service has no effect and, for example, does not delay the boot. That means, if the problem is a long boot time related to NetworkManager-wait-online.service, a possible solution is to investigate the services that claim to require network and fix those. For services that require network configured, NetworkManager-wait-online.service is the default implementation provided by NetworkManager to delay the target. But it does nothing magical. With special requirements, it may be sensible to disable NetworkManager-wait-online.service and replace it with a similar service that better implements the requirement. NetworkManager-wait-online.service blocks until NetworkManager logs "startup complete" and announces startup complete on D-Bus. How long that takes depends on the network and the NetworkManager configuration. If it takes longer than expected, then the reasons need to be investigated in NetworkManager. There are various reasons what affects NetworkManager reaching "startup complete" and how long NetworkManager-wait-online.service blocks. • In general, startup complete is not reached as long as NetworkManager is busy activating a device and as long as there are profiles in activating state. During boot, NetworkManager starts autoactivating suitable profiles that are configured to autoconnect. If activation fails, NetworkManager might retry right away (depending on connection.autoconnect-retries setting). While trying and retrying, NetworkManager is busy until all profiles and devices either reached an activated or disconnected state and no further events are expected. Basically, as long as there are devices and connections in activating state visible with nmcli device and nmcli connection, startup is still pending. • When a device reaches activated state, depends on its configuration. For example, with a profile with both IPv4 and IPv6 addressing enabled, the device is possibly considered fully activated when either of the address families is ready. This can be controlled with the ipv4.may-fail and ipv6.may-fail settings, to indicate that the address family is required. There are also ipv4.required-timeout and ipv6.required-timeout settings which affect how long to wait for an address family. Likewise, properties like ipv4.dhcp-timeout and ipv6.ra-timeout affect how long NetworkManager will try the IP configuration before giving up. • For example, a bridge or bond profile cannot do IP configuration without ports. When booting with such profiles that autoactivate without ports, NetworkManager-wait-online.service blocks until timeout. This is a configuration error. • Dispatcher scripts for the "pre-up" event run at a late stage during activation of a profile. These scripts block the activation for when NetworkManager considers the profile fully activated. See also NetworkManager-dispatcher(8) for details. • The connection property connection.wait-activation-delay also adds an additional delay during activation and delays startup complete. This is to workaround certain cases where a device is known to not be ready for a certain amount of time. • The property connection.wait-device-timeout of the connection profiles waits until the waited devices appear. This is useful if the driver takes a longer time to detect the networking interfaces. Similar with the connection.gateway-ping-timeout property. • With Wi-Fi devices, NetworkManager needs to wait for the first scan result to know which networks might be available. That always adds a delay. • With ethernet devices, NetworkManager waits for carrier until the configurable [device*].carrier-timeout is reached. This is because some devices take a long time to detect carrier and it means to boot with cable unplugged, will unnecessarily delay NetworkManager-wait-online.service. NetworkManager-wait-online.service internally uses nm-online.

BUGS

Please report any bugs in NetworkManager at the NetworkManager issue tracker[1].

NOTES

1. NetworkManager issue tracker https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues 2. NetworkManager home page https://networkmanager.dev

Источник

DESCRIPTION

The NetworkManager-wait-online service is a oneshot systemd service that delays reaching the network-online target until NetworkManager reports that the startup is completed on the D-Bus.

When the system boots, for example, remote mounts defined in /etc/fstab, require that the network is up. For this, these systemd units contain the After=network-online.target setting to order themselves after this target. NetworkManager-wait-online ensures that the network-online target is reached only after the network is available.

Optimally, all services on the host react dynamically to network changes and systemd services do not need to be configured to start after reaching the network-online target. In this case, NetworkManager-wait-online.service has no effect and does not delay the boot time. On the other hand, if you encounter a long boot time due to the delay of NetworkManager-wait-online, investigate the services that require network access and fix them.

Except for the time out value in the NetworkManager-wait-online.service unit, you cannot configure this service. Instead, settings in NetworkManager and the connection profiles affect the behavior:

•Startup is not complete as long as NetworkManager profiles are in an activating state. During boot, NetworkManager starts profiles with the connection.autoconnect=yes setting. If activation fails, NetworkManager retries the activation depending on the value of the connection.autoconnect-retries setting.

NetworkManager reports startup complete when all profiles and devices are either activated or in a disconnect state and no further events are expected.

•When a device reaches the activate state depends on its configuration. For example, with a profile that has both IPv4 and IPv6 enabled, by default, NetworkManager considers the device as fully activated already when only one of the address families is ready.

The ipv4.may-fail and ipv6.may-fail settings control this behavior. Additionally, the following settings influence when the two address families complete: ipv4.required-timeout, ipv6.required-timeout, ipv4.dhcp-timeout, and ipv6.ra-timeout. For details, see nm-settings-nmcli(5).

•NetworkManager cannot set IP addresses on bridge and bond devices that have ports that do not auto-activate. Because of this configuration error, NetworkManager-wait-online blocks until the service reaches its timeout value.

•Dispatcher scripts for the pre-up event run at a late stage during activation of a profile. These scripts block the activation for when NetworkManager considers the profile fully activated. For details, see NetworkManager-dispatcher(8).

•The property connection.wait-activation-delay adds an additional delay during activation and delays startup complete. This setting works around certain cases where a device is known to not be ready for a certain amount of time.

•The property connection.wait-device-timeout in the connection profiles cause a delay until the waiting devices appear. This is useful if the driver takes a longer time to detect the networking interfaces. This setting is similar to the connection.gateway-ping-timeout property.

•With Wi-Fi devices, NetworkManager needs to wait for the first scan result to know which networks are available. That adds a delay.

•With Ethernet devices, NetworkManager waits for the carrier until the value in [device*].carrier-wait-timeout is reached. This is because some devices take a long time to detect the carrier. Consequently, booting with cable unplugged, unnecessarily delays NetworkManager-wait-online.service.

BUGS

Please report any bugs in NetworkManager at the NetworkManager issue tracker[1].

NOTES

The website is available under the terms of the GPL-3.0 license, except for the contents of the manual pages, which have their own license specified in the corresponding Arch Linux package.

Источник

What does NetworkManager-wait-online.service do?

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:

sudo systemctl disable NetworkManager-wait-online.service

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

Is it needed if I use a wireless keyboard and mouse as input to my system (works with a wireless receiver adapter plugged into USB port)?

@Corni That is an excellent question but I’m not an expert on LAN/WAN/WiFi topology. I imagine it is something to do with negotiating new leases but that is just a guess. If you’re really curious you can post that as a new question on this site. For me it’s a shrug shoulders: it is what it is fact of life.

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

Источник

Linux networkmanager wait online service