NetworkManager-wait-online.service: NetworkManager Reference Manual

## NetworkManager-wait-online.service 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.

## See Also

NetworkManager home page, NetworkManager(8), nm-online(1),