Scroll to navigation

NETWORKMANAGER-WAIT-ONLINE(8) Network management daemons NETWORKMANAGER-WAIT-ONLINE(8)

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

SEE ALSO

NetworkManager home page[2], NetworkManager(8), nm-online(1),

NOTES

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