From 1372848511cb896b80b51ed1a3e9606bd9816631 Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Fri, 10 Feb 2023 11:50:34 +0100 Subject: New upstream version 1.42.0 --- .../html/NetworkManager-wait-online.service.html | 171 +++++++++------------ 1 file changed, 71 insertions(+), 100 deletions(-) (limited to 'docs/api/html/NetworkManager-wait-online.service.html') diff --git a/docs/api/html/NetworkManager-wait-online.service.html b/docs/api/html/NetworkManager-wait-online.service.html index 76b703a0..c951c7b6 100644 --- a/docs/api/html/NetworkManager-wait-online.service.html +++ b/docs/api/html/NetworkManager-wait-online.service.html @@ -24,132 +24,102 @@

NetworkManager-wait-online.service

-

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

+

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

Description

- NetworkManager-wait-online.service delays network-online.target until network - is ready. + 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.

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

- NetworkManager-wait-online.service itself is almost not configurable - itself. Instead the connection profiles and configuration in NetworkManager affects - the behavior. + 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.

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

-

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

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

    +
    • +

  • - 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 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). +

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

    • + 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. - See also NetworkManager-dispatcher(8) - for details. -

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

    • + 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 might be available. That always adds a delay. -

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

    • + With Ethernet devices, NetworkManager waits for the carrier until the value in + [device*].carrier-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. +

-

-

-

- NetworkManager-wait-online.service internally uses - nm-online. -

Bugs

@@ -164,6 +134,7 @@ NetworkManager home page, NetworkManager(8), nm-online(1), + the network-online.target description in systemd.special(7)

-- cgit 1.3.0-6-gf8a5 From dfaaf221cfee4ffcc507d793dae051d402646679 Mon Sep 17 00:00:00 2001 From: Michael Biebl Date: Thu, 9 Mar 2023 19:06:14 +0100 Subject: New upstream version 1.42.4 --- docs/api/html/NetworkManager-wait-online.service.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'docs/api/html/NetworkManager-wait-online.service.html') diff --git a/docs/api/html/NetworkManager-wait-online.service.html b/docs/api/html/NetworkManager-wait-online.service.html index c951c7b6..71b80e38 100644 --- a/docs/api/html/NetworkManager-wait-online.service.html +++ b/docs/api/html/NetworkManager-wait-online.service.html @@ -115,7 +115,7 @@

  • With Ethernet devices, NetworkManager waits for the carrier until the value in - [device*].carrier-timeout is reached. This is because some + [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.

    • -- cgit 1.3.0-6-gf8a5