From 9959fdb2e8ddd06f2161798ca0a39c77d67c652d Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Wed, 4 May 2022 15:35:24 +0200 Subject: New upstream version 1.37.92 --- man/NetworkManager-wait-online.service.xml | 169 +++++++++++++++++++++++++++++ 1 file changed, 169 insertions(+) create mode 100644 man/NetworkManager-wait-online.service.xml (limited to 'man/NetworkManager-wait-online.service.xml') diff --git a/man/NetworkManager-wait-online.service.xml b/man/NetworkManager-wait-online.service.xml new file mode 100644 index 00000000..d061643c --- /dev/null +++ b/man/NetworkManager-wait-online.service.xml @@ -0,0 +1,169 @@ + + + +%entities; +]> + + + + + + NetworkManager-wait-online.service + NetworkManager developers + + + NetworkManager-wait-online.service + 8 + NetworkManager-wait-online.service + Network management daemons + &NM_VERSION; + + + + 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. + + + + + 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. + + + + + Bugs + + Please report any bugs in NetworkManager at the + NetworkManager issue tracker. + + + + + See Also + + NetworkManager home page, + NetworkManager8, + nm-online1, + + + -- cgit 1.3.0-6-gf8a5