A boot pause close to two minutes can occur when systemd-networkd-wait-online.service cannot satisfy its definition of an online network. The systemd 257 documentation specifies a default timeout of 120 seconds.

Do not immediately disable the service. First identify the link holding it up and determine which services, mounts, or other units actually require network-online.target. The safest correction is usually to exclude one optional interface or wait for one explicitly required interface.

Confirm that wait-online caused the delay

Start with read-only checks against the current boot. Commands shown with sudo require administrator privileges; omit sudo if you are already working as root:

systemctl status systemd-networkd-wait-online.service
sudo journalctl -b -u systemd-networkd-wait-online.service
systemctl show systemd-networkd-wait-online.service \
  -p ActiveState -p Result -p ExecStart

Look for a timeout or failure associated with the service. Also inspect the effective command in ExecStart. The standard service invokes systemd-networkd-wait-online without options, but a local drop-in may already have changed its behavior.

Check whether the networkd and NetworkManager wait services are enabled:

systemctl is-enabled \
  systemd-networkd-wait-online.service \
  NetworkManager-wait-online.service

The systemd guidance notes that normally only the wait service corresponding to the active network manager should be enabled. A wait service affects boot when another unit pulls in network-online.target.

To inspect units associated with that synchronization point, use:

systemctl list-dependencies --reverse network-online.target

Pay particular attention to remote mounts and network client services. Remote mounts defined in /etc/fstab normally use network-online.target, so removing the wait can cause them to start before networkd considers the required connection online.

Understand what the service is waiting for

According to the systemd 257 wait-online documentation, the default service waits for all links known to and managed by systemd-networkd to become fully configured or failed. At least one managed link must also be online.

By default, “online” means an operational state equal to or higher than degraded. The service fails if its conditions are not met within 120 seconds. This explains why an optional Ethernet port, an unplugged secondary adapter, or another managed link that remains in a configuring state can coincide with a roughly two-minute pause.

The important distinction is that network.target merely indicates that the network management stack has started. network-online.target is an active synchronization point intended for software that cannot operate until networking has been configured.

Find the link preventing completion

List the links and compare their operational and setup states:

networkctl

A typical listing contains columns such as LINK, TYPE, OPERATIONAL, and SETUP. Examine individual candidates for more detail:

networkctl status enp1s0
networkctl status enp2s0

Replace the example names with those shown on your machine. A secondary interface that is intentionally unplugged should not necessarily have the same boot requirement as the primary interface carrying remote mounts or other essential traffic.

Before changing anything, classify each managed interface:

• Required: boot-time clients or remote mounts need this specific connection.
• Alternative: either Ethernet or Wi-Fi may provide sufficient connectivity.
• Optional: the interface may legitimately remain disconnected at boot.
• Misconfigured: the interface is expected to work but remains stuck because its network configuration is incomplete.

Fix a required but misconfigured interface rather than excluding it from the online decision.

Choose the narrowest correction

Mark one optional link as not required

If a particular interface is managed by networkd but is not needed during boot, add only RequiredForOnline=no to the [Link] section of its existing, correctly matched .network file:

[Link]
RequiredForOnline=no

Keep the existing [Match], [Network], and any other sections unchanged, including DHCP or static IP settings. This is a fragment to add to an existing file, not a complete replacement network configuration. Confirm which file matches the interface before editing; avoid broad matches that could affect other interfaces. Locally administered network files typically live under /etc/systemd/network/. Back up the original file before editing.

Warning: Restarting systemd-networkd may interrupt active interfaces, routes, and your SSH connection. On a remote server, arrange working console or out-of-band access and a tested rollback plan before applying the change. Do not restart networkd over your only remote connection if losing access would lock you out. Apply the change during a maintenance window or controlled reboot if appropriate.

Only when you have a safe recovery path, apply the updated configuration:

sudo systemctl restart systemd-networkd.service

This option preserves normal wait-online behavior for every other managed link while removing the optional link from the online requirement.

Wait for one specific interface

The instantiated unit accepts an interface name and waits for that interface to be configured and online. For example:

systemd-networkd-wait-online@enp1s0.service

This is appropriate when one known interface must carry boot-critical network traffic and all other interfaces are irrelevant to that requirement.

Warning: Changing enabled units alters future boots. Verify the interface name and confirm that it is the connection required by remote mounts and network-dependent services before proceeding.

sudo systemctl disable systemd-networkd-wait-online.service
sudo systemctl enable systemd-networkd-wait-online@enp1s0.service

Before the next reboot, confirm that the intended instance is enabled, the generic unit is no longer enabled, and network-online.target pulls in the selected unit:

systemctl is-enabled systemd-networkd-wait-online.service
systemctl is-enabled systemd-networkd-wait-online@enp1s0.service
systemctl list-dependencies network-online.target
systemctl cat systemd-networkd-wait-online@enp1s0.service

Expect the generic unit to report disabled, the interface-specific unit to report enabled, and the instance to appear among the dependencies of network-online.target. If those checks do not match, investigate before rebooting. After boot, inspect the status and journal of the instance, not only the generic service.

The instance uses the equivalent of --interface=enp1s0. When an interface is selected this way, other interfaces are ignored. Multiple --interface options require all named interfaces unless combined with --any.

Ignore one interface with a service drop-in

A service drop-in can retain the generic unit while excluding a known optional interface. The empty ExecStart= line resets the original command before the replacement is defined:

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --ignore=enp2s0

Save it as:

/etc/systemd/system/systemd-networkd-wait-online.service.d/override.conf

Warning: This changes the service’s effective startup command. Copy the executable path from the local unit or its current ExecStart output instead of assuming that every installation uses an identical vendor file.

After creating or changing the drop-in, reload the systemd manager and inspect the merged unit:

sudo systemctl daemon-reload
systemctl cat systemd-networkd-wait-online.service
systemctl show systemd-networkd-wait-online.service -p ExecStart

The --ignore= option may be repeated if several specifically identified interfaces are optional. Loopback is ignored by default.

Accept whichever connection comes online first

On a machine where several managed links are valid alternatives, --any allows wait-online to succeed when at least one interface becomes online, even if another remains in the configuring state:

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --any

This is broader than excluding one known optional link. Use it only when any managed online interface genuinely satisfies the system’s boot-time network requirement.

Shorten the timeout only when failure is acceptable

The --timeout=SECS option changes how long the service waits. A timeout of zero disables the timeout, which can make the wait unbounded and is generally unsuitable for diagnosing a boot delay.

For example, this drop-in limits the wait to 30 seconds:

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --timeout=30

A shorter timeout does not correct the underlying interface state. It merely makes wait-online fail sooner, so dependent units can still encounter an unavailable network.

Do not disable the wait blindly

Disabling or masking wait-online can appear to remove the pause, but it also removes the synchronization used by genuine consumers of network-online.target. The upstream guidance identifies remote mounts and network client software that cannot operate without connectivity as typical consumers.

Broad disablement is more defensible only after confirming that nothing boot-critical needs the target. Even then, dynamic services should handle later network changes and temporary loss of connectivity rather than assuming the network remains continuously available.

Verify the correction after a controlled reboot

Warning: A reboot terminates sessions and may expose a configuration error that prevents remote access. Ensure that you have a recovery path before rebooting a remote machine.

After the next boot, repeat the read-only checks for the wait-online unit you actually configured:

systemctl status systemd-networkd-wait-online.service
sudo journalctl -b -u systemd-networkd-wait-online.service
networkctl

If you enabled the interface-specific unit instead, also check its status and journal (replace enp1s0 with your real interface):

systemctl status systemd-networkd-wait-online@enp1s0.service
sudo journalctl -b -u systemd-networkd-wait-online@enp1s0.service

Then verify the actual consumers rather than checking boot speed alone:

• Confirm that required remote mounts are mounted.
• Confirm that boot-time network clients reached their expected services.
• Confirm that the designated interface has the operational state required by the configuration.
• Test both connected and intentionally disconnected interface combinations where the machine supports alternative links.

A successful result is not merely a shorter boot. It is a shorter boot in which every service that genuinely needs connectivity still starts with the required network available.