If your system is sticking around for 2-3 minutes during boot, labelled something like “Waiting for network to be configured…” (or equivalent), the likely culprit is this service waiting for interfaces to reach the expected state — and then timing out when they don’t. There are a number of reasons this happens:
Typical causes
- Unused or un-plugged interfaces
If you have multiple network interfaces (for example one wired, one wireless, or a virtual interface) and one of them is not connected or stuck in “configuring” state, systemd-networkd-wait-online may wait until the timeout. Indeed there is a bug filed: when one of multiple interfaces is not physically connected, the service delays boot until the timeout (≈150 s) expired.
GitHub+2
Proxmox Support Forum+2 - Interfaces not managed by systemd-networkd
If the interface configuration is handled by another tool (e.g., ifupdown, NetworkManager, or other), but you still have systemd-networkd-wait-online enabled, systemd-networkd might not see those interfaces as “configured” and wait anyway. The Debian wiki mentions this scenario.
wiki.debian.org+1 - Mis-configuration of .network files or RequiredForOnline setting
The .network files used by systemd-networkd can include the RequiredForOnline= setting; if these are mis-specified, the link may be considered “not yet online”. Additionally, interfaces might not gain carrier (physical link) or IP address in the expected time. - The default timeout is too long
Since the default timeout is 120 seconds, plus some overhead, you might see ~2-3 minutes of “stall” before the service fails and boot continues. For example, users on Debian 13/Proxmox templates have reported ~1-2 minute delays: “Timeout occurred while waiting for network connectivity.”
Proxmox Support Forum
What this looks like in logs
You’ll typically find something like:
systemd[1]: Starting Wait for Network to be Configured... systemd-networkd-wait-online[XXXX]: Timeout occurred while waiting for network connectivity. systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
And then boot continues. This delay may also hold up other units that depend on network-online.target.
How to troubleshoot & fix the delay on Debian 13
Here’s a step-by-step guide tailored for Debian 13 systems.
1. Understand what your system uses for networking
- Are you using systemd-networkd, or something else (e.g. NetworkManager, ifupdown, netplan)?
- Run networkctl to list links and see their configuration status.
- Check which service is managing the interfaces (look for .network files in /etc/systemd/network/, /lib/systemd/network/, etc).
2. Inspect the .network files and settings
If you are using systemd-networkd:
- Check for .network files under /etc/systemd/network/ or /lib/systemd/network/ and verify settings such as RequiredForOnline= if present.
- In the man page: you can use --interface=INTERFACE to limit the wait to particular interface(s).
Debian Manpages - Decide whether you really need to wait for all links, or only one critical link (e.g., your primary wired interface).
3. Adjust or limit the wait behaviour
If you find that you don’t need to wait for every interface (or some interfaces rarely connect), you can:
- Create a drop-in override file to narrow the interfaces to wait for. For example:
mkdir /etc/systemd/system/systemd-networkd-wait-online.service.d/ cat <<EOF > /etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf [Service] ExecStart= ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --interface=eth0 --any EOF systemctl daemon-reload
- This instructs it to only wait for eth0, and succeed when any interface is online. (Adapt eth0 to your interface name.)
- Alternatively, reduce the timeout. For example add --timeout=30 (30 seconds) rather than the default 120s. The man page notes --timeout=SECS sets the timeout.
Debian Manpages+1
4. Disable or mask the service if not required
If your system does not actually require waiting for “network online” (for example it boots fast and most services are tolerant of network coming up later), you can disable or mask the service:
systemctl disable systemd-networkd-wait-online.service systemctl mask systemd-networkd-wait-online.service
Caution: If you have services that rely on the network being fully configured before they start, disabling this may cause issues (those services may start too early).
5. Check for physical link / interface issues
Since one common cause is unplugged or mis-managed interfaces:
- Use ip link or networkctl to see interfaces in “configuring” or “no carrier” state.
- If you have virtual or stray interfaces (e.g., a second NIC slot not used, a VPN interface always “down”), consider ignoring them in the wait service via --ignore=INTERFACE (supported from certain version) or by setting RequiredForOnline=no in .network.
Debian Manpages - Ensure that your primary interface actually gets link carrier and address quickly.
6. Review journal logs for clues
Use journalctl to see what happened during boot:
journalctl -b -u systemd-networkd-wait-online.service
Look for lines like “Timeout occurred while waiting for network connectivity” and note how long the service spent.
7. Upgrade if bug already fixed
The issue tracker for systemd lists some bugs where this delay happens because one interface is down/unplugged.
GitHub+1
Ensure your Debian 13 system is updated (including systemd package) so you benefit from any fixes.
Summary & Recommendations
- The boot delay (~2–3 minutes) is very likely caused by systemd-networkd-wait-online.service waiting for network links that don’t come up in time or at all.
- You don’t always need to wait for all links; often waiting for one “critical” interface suffices.
- You can either narrow what the wait service monitors, reduce the timeout, or disable/mask it if your system doesn’t require it.
- Always make sure your interface configuration (via .network or other) correctly reflects reality (e.g., unused interfaces disabled, required ones active).
- If you use a different networking stack (e.g., NetworkManager), you might not want this service at all.