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