NETWORKMANAGER-WAIT-ONLINE.SERVICE(8)

📦
version 1.58.0 · 20 versions
, in centos-stream 10

💅 NetworkManager-wait-online.service(8) — like, the "wait for the internet bestie" page

okay so you're reading the manual for NetworkManager-wait-online.service, which lives in the Network management daemons neighborhood. grab a lil snack, we're gonna get into it 🍓

✨ NAME ✨

NetworkManager-wait-online.service — literally just wait for the network to come online. that's the whole job. iconic behavior, honestly. 🎀

🌸 DESCRIPTION 🌸

so the NetworkManager-wait-online service is a oneshot systemd service (yes, oneshot — it does its thing once and dips), and what it does is delay reaching the network-online target until NetworkManager reports on the D-Bus that the startup is completed. no cap, that's the entire vibe check. 🦋

when the system boots, remote mounts defined in /etc/fstab (for example) need the network to actually be up, right? so for that, these systemd units contain the After=network-online.target setting, so they order themselves after this target. and NetworkManager-wait-online is the one making sure the network-online target is reached only after the network is actually available. she's the bouncer at the club 💅

optimally, all services on the host react dynamically to network changes, and systemd services don't need to be configured to start after reaching the network-online target. in that case, NetworkManager-wait-online.service has no effect and does not delay the boot time. slay, zero waste. but on the other hand — if you're out here with a long boot time due to the delay of NetworkManager-wait-online, go investigate the services that require network access and fix them. respectfully, that's a you problem, not a NetworkManager problem 😭

except for the time out value in the NetworkManager-wait-online.service unit, you cannot configure this service. nope, not a thing. instead, settings in NetworkManager and the connection profiles affect the behavior, and here's the full tea:

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

  • 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. lowkey efficient, highkey chaotic.

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. yeah. she's just standing there waiting. awkward 💀
  • 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. it's giving "we know she's late, we built in a buffer" 🙈
  • 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. scanning the vibes, basically 🌈
  • 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 the cable unplugged unnecessarily delays NetworkManager-wait-online.service. ma'am. plug it in. 🔌

🐛 BUGS 🐛

please report any bugs in NetworkManager at the NetworkManager issue tracker. do it for her. 💜

🔥 SEE ALSO 🔥

📝 NOTES 📝

  1. NetworkManager issue tracker https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues
  2. NetworkManager home page https://networkmanager.dev
bestie reminder: everything above is straight facts from the page — the time out value in the unit is genuinely the only knob you get here. everything else is controlled by NetworkManager settings and your connection profiles, iykyk ✨

and that's the whole page!! this one's brought to you by NetworkManager-wait-online (that's the source, babes) with its NETWORKMAN...AIT-ONLINE(8) header energy — mwah, go touch grass while your boot finishes 🌸🎀💖

📦 where this page comes from