Skip to content

Raspberry Pi Slow Boot: NetworkManager Wait Online Diagnosis

If NetworkManager-wait-online.service appears near the top of systemd-analyze blame, first check whether it delays the application you need. On Raspberry Pi OS Bookworm and Trixie, network startup and the systemd dependency graph can explain a long boot even when the Pi eventually connects successfully.

Quick diagnosis for NetworkManager wait-online

1
2
3
4
5
6
# Inspect this boot without changing networking or stopping SSH.
systemd-analyze time
systemd-analyze critical-chain
systemd-analyze critical-chain network-online.target
systemctl status NetworkManager-wait-online.service --no-pager
journalctl -b -u NetworkManager -u NetworkManager-wait-online --no-pager
Observation Investigate next
Wait service is slow but outside the application's critical path Measure actual application readiness before changing it
A profile repeatedly activates and fails Link, credentials, DHCP, and autoconnect configuration
Boot is slow only with Ethernet unplugged Carrier waiting and whether the profile is required
Network mount or remote-data service waits Fix its required connection and retain ordering
SSH works early but an API is late Inspect the API's unit and startup logs

What network-online.target does and does not mean

NetworkManager-wait-online delays the target while NetworkManager completes startup. This can include connection attempts that eventually fail; it is not a guarantee that your particular remote endpoint is reachable. A later cable disconnect does not cause the boot target to become a live connectivity monitor.

After=network-online.target expresses ordering. A service that needs the target must also pull it in through an appropriate dependency, commonly Wants=network-online.target. Services which bind locally and can handle connection changes may not need this boot-time wait. See systemd's explanation of network targets before editing dependencies.

1. Find the units requesting the wait

1
2
3
4
# Inspect dependencies and the installed wait-service command.
systemctl list-dependencies --reverse network-online.target
systemctl cat NetworkManager-wait-online.service
systemctl is-enabled NetworkManager-wait-online.service

For the actual consumer, substitute its name for your-app.service:

1
2
3
4
systemctl cat your-app.service
systemctl show your-app.service -p After -p Wants -p Requires
systemd-analyze critical-chain your-app.service
journalctl -b -u your-app.service --no-pager

Include remote mounts in the investigation. A dependency list is a clue, not a complete audit of every application expectation. Do not remove a wait needed to make a network-backed database, storage mount, or startup download reliable.

2. Identify the connection profile holding up startup

1
2
3
4
5
# List devices and profiles without revealing saved Wi-Fi passwords.
nmcli device status
nmcli connection show
nmcli connection show --active
journalctl -b -u NetworkManager -o short-monotonic --no-pager

Use the UUID reported by nmcli connection show to inspect a suspect profile:

1
2
3
# Replace this with the UUID of the profile you are investigating.
PROFILE_UUID='replace-with-profile-uuid'
nmcli -f connection.id,connection.uuid,connection.autoconnect,connection.autoconnect-retries,ipv4.method,ipv4.may-fail,ipv6.method,ipv6.may-fail connection show "$PROFILE_UUID"

The NetworkManager wait-online documentation describes several causes: activation retries, address-family requirements, Wi-Fi scanning, Ethernet carrier waits, bridge or bond configuration, and dispatcher scripts. Match the logs to one of these rather than shortening every timeout.

Avoid --show-secrets when collecting logs for a public issue. Keep an existing SSH session and a local recovery route before modifying the profile carrying your remote connection.

3. Correct a confirmed-unused autoconnect profile

A stale profile is a candidate only when it is not needed for this appliance, fallback access, or a bridge/bond port. Record its existing autoconnect value before editing:

1
2
3
nmcli -g connection.autoconnect connection show "$PROFILE_UUID"
# Apply only to the confirmed-unused profile, not your remote-access profile.
sudo nmcli connection modify "$PROFILE_UUID" connection.autoconnect no

This preserves the profile for manual use. It does not disconnect it immediately. Reboot during a planned test and verify the required connections. To undo the change, restore the exact recorded value; if it was yes:

1
sudo nmcli connection modify "$PROFILE_UUID" connection.autoconnect yes

For a required connection, fix the underlying problem instead: link or Wi-Fi authentication, router DHCP availability, duplicate/static addressing, or broken profile dependencies. Use the NetworkManager setup guide for those checks.

4. Keep IPv4 and IPv6 requirements deliberate

Changing ipv4.may-fail or ipv6.may-fail changes the conditions for profile activation. It does not repair a failing DHCP server or make a specific remote service reachable. Inspect the installed man nm-settings-nmcli and the profile property reference for your version.

Keep an address family mandatory when the application requires it. Do not disable IPv6 globally because one profile is slow. Likewise, increasing retry counts can turn a configuration error into a longer boot, while aggressive short timeouts can make a working but slower network fail.

5. When can you disable the wait service?

Consider it only after checking all consumers and proving they handle network availability themselves. A local kiosk can have different requirements from a NAS with remote mounts. Record the original enabled state first, and use a spare image or local console for the experiment.

1
2
3
# Disable the boot wait only after the dependency and readiness checks above.
systemctl is-enabled NetworkManager-wait-online.service
sudo systemctl disable NetworkManager-wait-online.service

Disabling this unit does not disable NetworkManager itself. Explicit dependencies may still pull the wait service into a boot transaction; inspect the next boot to establish what happened. Do not mask it as a universal fast-boot fix.

If the unit was originally enabled, rollback is:

1
sudo systemctl enable NetworkManager-wait-online.service

Restore the previous state when it differed. Do not use disable --now NetworkManager to solve a wait-service delay; that stops the network manager and can break remote access.

Verify a useful improvement

Compare at least five equivalent boots before and after one change. Record the median, range, connection method, attached hardware, and the moment the actual application becomes ready. Include boots with the expected network unavailable if the appliance must support that condition.

Check the following after each boot:

1
2
3
4
systemd-analyze time
systemd-analyze critical-chain
nmcli device status
systemctl --failed

Also test a fresh SSH login, required network mounts, DNS, and your application's health endpoint. A smaller userspace timing number is not enough if the application now fails intermittently.

References checked on 3 October 2026. Commands are diagnostic examples; no boot-speed result is claimed without measurements on named Raspberry Pi hardware.