|  |  |  |  | 
| NetworkManager-wait-online.serviceNetworkManager-wait-online.service — Wait for network to come online | 
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.
          
            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.
          
            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.
          
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.