NetworkManager-wait-online.service: NetworkManager Reference Manual

- - -

NetworkManager-wait-online.service

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

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