Diagnose and Tune NetworkManager-wait-online Delays

A slow boot that blames NetworkManager-wait-online.service is rarely the wait service's own fault. This guide gets you a measured explanation instead of papering over the delay with a shorter timeout. The examples use NetworkManager 1.46.0 from Ubuntu package network-manager 1.46.0-1ubuntu2.8 and systemd's installed unit.

Allow about fifteen minutes. You need a shell and permission to read service status and logs, the investigation itself is read-only. The optional timeout change near the end needs sudo and affects later boots, so treat it as a configuration change, not a diagnostic shortcut.

1. Confirm What the Service Actually Waits For

Read the unit that is actually installed on your machine:

$ systemctl cat NetworkManager-wait-online.service
# /usr/lib/systemd/system/NetworkManager-wait-online.service
[Service]
Type=oneshot
ExecStart=/usr/bin/nm-online -s -q
RemainAfterExit=yes
Environment=NM_ONLINE_TIMEOUT=60

Exact comments and unit path can vary. What matters here is Type=oneshot, the nm-online -s -q command, and the 60-second NM_ONLINE_TIMEOUT. -s waits for NetworkManager's startup to settle, it does not mean every interface has a working route the instant the command returns.

$ systemctl show NetworkManager-wait-online.service \
    -p ActiveState -p SubState -p Result -p ExecMainStatus -p TimeoutStartUSec
ActiveState=active
SubState=exited
Result=success
ExecMainStatus=0
TimeoutStartUSec=infinity

active (exited) is normal for a oneshot service like this one. It has finished waiting and stays recorded as active purely for dependency ordering.

2. Measure the Wait Outside a Boot

Run the same helper in quiet startup mode and time it. This only asks NetworkManager for its current startup state, it does not restart networking:

$ time nm-online --wait-for-startup --quiet

real    0m0.0s
user    0m0.0s
sys     0m0.0s

A machine that already finished startup returns instantly. One still waiting on a device, profile or dispatcher action can take longer, the timing is host-specific, so do not treat the numbers above as a promised default.

For a direct pass or fail, run:

$ nm-online --wait-for-startup --quiet
$ printf 'nm-online status: %s\n' "$?"
nm-online status: 0

Status 0 means startup completed. Anything else means the wait did not succeed, keep that result alongside the service logs before you change anything.

3. Find the Connection Holding Startup Open

List device and connection state as an ordinary user:

$ nmcli device status
DEVICE  TYPE      STATE      CONNECTION
enp1s0  ethernet  connected  Wired connection 1
wlan0   wifi      disconnected  --
lo      loopback  unmanaged   --

Your interface names and states will differ. Look for a device stuck in connecting, a profile that keeps failing, or an auto-connecting Wi-Fi profile on a machine nowhere near its access point. A disconnected device is not automatically a fault, NetworkManager can reach startup complete once every relevant profile and device lands in a conclusive state.

Inspect profiles without printing secrets:

$ nmcli -f NAME,UUID,TYPE,AUTOCONNECT connection show
NAME                 UUID                                  TYPE      AUTOCONNECT
Wired connection 1   11111111-2222-3333-4444-555555555555  ethernet  yes

Do not copy a UUID from this example, use the exact name or UUID from your own output. If activation keeps retrying, check its logs and settings rather than disabling the wait service.

4. Read the Boot and NetworkManager Evidence

Ask systemd how long the unit actually took, and pull messages from the current boot:

$ systemd-analyze blame | grep NetworkManager-wait-online
  1.842s NetworkManager-wait-online.service
$ journalctl -b -u NetworkManager-wait-online.service --no-pager
$ journalctl -b -u NetworkManager.service --no-pager

The duration is specific to this boot. In the NetworkManager log, look for a profile stuck activating, repeated DHCP or IPv6 attempts, a missing bridge or bond port, a slow pre-up dispatcher script, or a device that has not appeared yet. Wi-Fi also waits for an initial scan, and Ethernet waits for carrier, so an unplugged cable is relevant too.

A successful wait does not mean a healthy network. This service only reports that NetworkManager's startup work reached a conclusion, it is a boot-ordering gate for units using network-online.target, not a continuous connectivity monitor.

5. Fix the Cause, Not the Symptom

Fix the profile that is slow or impossible to activate: correct a bridge or bond whose ports do not auto-activate, remove an obsolete auto-connect profile, or fix DHCP, IPv4 and IPv6 requirements. Change one thing at a time and write down the previous setting first.

Settings such as ipv4.may-fail, ipv6.may-fail, DHCP and router-advertisement timeouts, connection.wait-device-timeout and connection.wait-activation-delay all change when startup counts as complete, and they mean different things operationally. Do not set them just to make boot look faster, especially on a host that needs a particular address family or interface up before it mounts remote storage.

6. Change the Timeout Only With a Reason

If the network genuinely needs longer than the installed 60 seconds, override the service environment with a systemd drop-in. This does not fix activation, it only lets the wait run longer:

$ sudo systemctl edit NetworkManager-wait-online.service

Add this drop-in in the editor, with a value that suits the host:

[Service]
Environment=NM_ONLINE_TIMEOUT=120

Save, close the editor, then verify the effective configuration:

$ systemctl cat NetworkManager-wait-online.service
$ systemctl show NetworkManager-wait-online.service -p Environment
Environment=NM_ONLINE_TIMEOUT=120

Apply it on the next service start or reboot, whichever fits your maintenance plan. To undo it, remove all local overrides for this unit and confirm the vendor value is back:

$ sudo systemctl revert NetworkManager-wait-online.service
$ systemctl cat NetworkManager-wait-online.service