How can I prevent the NetworkManager-wait-online.service from starting at boot on Ubuntu 24.04?

You can prevent the NetworkManager-wait-online.service from starting at boot on Ubuntu 24.04 using the systemctl command to either disable or mask the service.

This service's purpose is to delay the boot process until the network connection is fully established, which can cause significant delays if the network is slow or unavailable. Disabling it is generally safe for desktop users who don't rely on network resources (like remote mounts or network-dependent services) immediately after startup.

---

🛑 How to Disable the Service

The recommended and most common approach is to use the disable command. This removes the symlink that causes the service to start automatically.

1. Run the disable command:

   Bash

   sudo systemctl disable NetworkManager-wait-online.service
   

2. Reboot your system to confirm the change.

🎭 If Disabling Doesn't Work: Masking (The Stronger Approach)

In some cases, another service might still have a dependency that causes the NetworkManager-wait-online.service to be started anyway. If the disable command doesn't work, you can mask the service. Masking creates a symlink to /dev/null, preventing any service from starting it, even manually or as a dependency.

1. Run the mask command:

   Bash

   sudo systemctl mask NetworkManager-wait-online.service
   

2. Reboot your system.

---

↩️ How to Revert the Change

If you later find that you need the service to wait for the network (for example, if a service or application that relies on an immediate network connection fails to start), you can easily revert the changes.

• For a Disabled Service:

  Bash

  sudo systemctl enable NetworkManager-wait-online.service
  

• For a Masked Service:

  You must first unmask it, and then enable it:

  Bash

  sudo systemctl unmask NetworkManager-wait-online.service
  sudo systemctl enable NetworkManager-wait-online.service
  

Would you like to check which other services are delaying your boot time using systemd-analyze blame?

Can I prevent the service from starting at boot by editing any text file?

Yes, you can prevent the NetworkManager-wait-online.service from starting at boot by editing a text file—specifically, by manually removing the symbolic link that is created when the service is "enabled."

The systemctl disable command is just an automated way of doing this file manipulation.

---

1. Deleting the Systemd Symlink

When a systemd service is "enabled," a symbolic link is created in a "wants" directory that points to the main unit file. Removing this link is equivalent to running systemctl disable.

For NetworkManager-wait-online.service, the symlink is usually found in the multi-user.target.wants directory, which controls services that start up for a multi-user environment.

1. Navigate to the multi-user.target.wants directory:

   Bash

   cd /etc/systemd/system/multi-user.target.wants/
   

2. Delete the symbolic link:

   Bash

   sudo rm NetworkManager-wait-online.service
   

3. Reload the systemd manager configuration (Required):

   After making a manual change to a unit file or its symlinks, you must tell systemd to re-read its configuration:

   Bash

   sudo systemctl daemon-reload
   

4. Verify the service is now disabled:

   Bash

   systemctl is-enabled NetworkManager-wait-online.service
   

   This should now output disabled.

---

2. The Stronger File-Based Method: Masking

If simply disabling the service doesn't work (because another service has a dependency that still triggers it), you need to "mask" the service. Masking is the strongest way to prevent a systemd unit from starting, and it is also done by manipulating a file.

Masking is achieved by creating a symbolic link in /etc/systemd/system that points to /dev/null. This tells systemd to effectively ignore the service.

1. Create the symbolic link to /dev/null:

   Bash

   sudo ln -s /dev/null /etc/systemd/system/NetworkManager-wait-online.service
   

2. Reload the systemd manager configuration (Required):

   Bash

   sudo systemctl daemon-reload
   

3. Verify the service is now masked:

   Bash

   systemctl status NetworkManager-wait-online.service
   

   The output will show the service as "masked".

Note: The systemctl disable and systemctl mask commands are the recommended way to do this, as they handle the file system pathing and the necessary daemon-reload for you, reducing the chance of error.

As you suggested earlier, could you let me know how to check which other services are delaying my boot time using systemd-analyze blame, please? Thank you!

Yes! The tool is called systemd-analyze, and the subcommand you want is blame. ¹It generates a list of all startup services, sorted by the time they took to initialize, with the longest delays at the top.²

Here is a step-by-step guide on how to use it.

---

💻 Step 1: Run the systemd-analyze blame Command

Open your terminal and run the following command. You do not need sudo for this command.

Bash

systemd-analyze blame

Example Output

The output will look similar to this, with the slowest services listed first:

Time	Service
5.417s	NetworkManager-wait-online.service
1.275s	udisks2.service
1.054s	snapd.service
789ms	dev-sda5.device
452ms	apache2.service
230ms	systemd-udev-settle.service

---

🔍 Step 2: Analyze the Output

The list shows the services, or units, in descending order of how long they spent in the "activating" state during the last boot.³

• The first column shows the time taken (e.g., 5.417s for 5.417 seconds).⁴

• The second column is the name of the unit (e.g., NetworkManager-wait-online.service).

Key Takeaways:

1. Identify Offenders: Focus on the services at the very top of the list (like NetworkManager-wait-online.service in the example above).⁵ These are the main "culprits" that added the most time to your overall boot.

2. Units Run in Parallel: Keep in mind that many services run at the same time.⁶ You cannot simply add all the times together to get your total boot time. The list helps you spot single services that spend a lot of time by themselves.

---

🌲 Step 3: Check the Critical Chain (Optional but Recommended)

While blame shows you which services took the longest, the critical-chain subcommand is better for identifying bottlenecks—services that block the boot process until they complete.⁷

Bash

systemd-analyze critical-chain

Example Output

graphical.target @20.123s
└─multi-user.target @20.123s
  └─ NetworkManager-wait-online.service @14.706s +5.417s
    └─ NetworkManager.service @13.900s +780ms
      └─ dbus.service @13.890s

• @ (At): The time when the unit became active or started.

• + (Plus): The time the unit took to start (the delay).⁸

In this example, the chain shows that NetworkManager-wait-online.service (which took +5.417s) was a dependency for the main target to be reached. This confirms it was a blocker, just as you suspected!

You can also generate a visual SVG graph of the boot process for a more intuitive view of dependencies and parallel startup, by using the following command:

Bash

systemd-analyze plot > boot.svg

You can then open the boot.svg file in a web browser to see a detailed, color-coded timeline.

---

Once you've identified the high-time services, you can then use systemctl disable or systemctl mask (as discussed in our previous exchange) on non-essential ones to speed up your boot.