Job for NetworkManager.service failed because the control process exited with error code

Check the permissions on your connection files first. NetworkManager refuses to load any keyfile under /etc/NetworkManager/system-connections/ that is readable by anyone but root, because those files hold wifi and VPN secrets. Wrong permissions are the most common cause and the error never says so plainly.

ls -l /etc/NetworkManager/system-connections/
sudo chmod 600 /etc/NetworkManager/system-connections/*
sudo chown root:root /etc/NetworkManager/system-connections/*

A file copied from a backup, pulled from configuration management, or edited as a normal user arrives with 644 and is silently ignored or rejected.

Before you restart this on a remote machine

NetworkManager owns the connection you are using. Restarting it over SSH can drop you, and unlike sshd there is no forked child keeping your session alive if the interface itself goes down. If the host has a serial or provider console, confirm you can reach it first. If it does not, prefer sudo nmcli connection reload, which re-reads profiles without restarting the daemon, over a full restart.

Make sure it is NetworkManager that failed

There are two units with similar names and people routinely debug the wrong one. NetworkManager-wait-online.service exists only to delay boot until the network is up. It fails on its own timeout whenever no connection is configured to come up automatically, and that failure is noisy, harmless and completely separate from NetworkManager itself.

systemctl status NetworkManager.service
systemctl status NetworkManager-wait-online.service

If the first is active and only the second is failed, your network is working and the failure is cosmetic. Disable the wait-online unit if the delay bothers you; do not go hunting through NetworkManager configuration.

The other causes, in order

1. D-Bus is not running. NetworkManager cannot start without the system message bus and exits immediately if it is down. Check systemctl status dbus before anything else, since a failed D-Bus takes several services with it and NetworkManager is usually the loudest.
2. A malformed keyfile. A hand-edited connection file with a bad key, a missing section header or a UUID that is not valid stops the load. Validate the whole directory with sudo nmcli connection reload then nmcli connection show: a profile that disappears from the list is the broken one.
3. Two profiles claiming the same interface. Duplicate autoconnect profiles for one device make activation ambiguous. The journal says a connection was activated but no suitable device was found, or flaps between profiles. Delete the stale one with sudo nmcli connection delete <uuid>.
4. The ifupdown plugin conflicting on Debian. If /etc/network/interfaces still configures an interface and NetworkManager is also managing it, the two fight. Decide which owns the interface and remove it from the other.
5. Start request repeated too quickly. If the journal says this, systemd rate-limited the restarts rather than NetworkManager failing on this attempt. Clear it with sudo systemctl reset-failed NetworkManager and start once, then read the actual first failure instead of the rate-limit message.

Reading the exit code

status=1/FAILURE means the daemon started and rejected something, so read the journal. status=203/EXEC means the binary named in the unit does not exist or is not executable, which happens after a partial upgrade. For NetworkManager-wait-online specifically, a timeout result rather than an exit code confirms it is the harmless case described above. The full table is in the nginx version of this error.

How to stop it happening again

sudo nmcli connection reload && nmcli connection show

Reload rather than restart whenever you change a profile. It re-reads every keyfile without touching active connections, so a bad file costs you nothing and a profile that fails to load simply does not appear in the list. Keep the chmod 600 step in whatever process writes those files, because configuration management tools are the most common source of the permission problem at the top of this page.

Related

• Job for ssh.service failed: the other service that can lock you out of a remote machine.
• Job for nginx.service failed: the same systemd error, plus the full exit-code table.
• systemd service unit generator: build units with correct ordering against network-online.target.