NetworkManager restart loop fix: 3 real causes

1. DNS config conflict (resolv.conf is a directory)

This is the one I see most often. NetworkManager uses dnsmasq or systemd-resolved to handle DNS. If /etc/resolv.conf is a directory instead of a file, dnsmasq refuses to start. NetworkManager detects dnsmasq failed, restarts it. Repeat forever.

How this happens: some container runtimes (Docker, LXC) or VPN clients (OpenVPN) can accidentally replace the resolv.conf symlink with a directory. On Ubuntu 22.04, I saw this after a Docker install that messed with network namespaces.

Check it:

ls -la /etc/resolv.conf

If it shows drwxr-xr-x (directory), that's your problem. The fix is simple:

rm -rf /etc/resolv.conf
ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf
systemctl restart NetworkManager

On RHEL/Fedora, the symlink target is /run/NetworkManager/resolv.conf instead. Use that if systemd-resolved isn't running.

Why step 3 works: dnsmasq reads resolv.conf at startup. When it's a directory, dnsmasq errors out instantly. NetworkManager sees the failure and loops trying to restart dnsmasq. The symlink fixes the read path.

2. Corrupted interface configuration in /etc/NetworkManager/system-connections

NetworkManager stores per-interface settings in /etc/NetworkManager/system-connections/. If one of those files has a syntax error — missing closing bracket, bad key name, or a UUID conflict — the profile fails to load. NetworkManager then tries to reload the profile, fails again, and restarts the service. It's a silent loop.

I ran into this on a CentOS 7 box after someone hand-edited a connection file with a typo: permissions= instead of permission=. The file looked fine but the key was wrong.

Diagnose with:

journalctl -u NetworkManager -n 50 | grep -i error

You'll see something like: Error loading connection: invalid key 'permissions'. To fix, find the bad file:

cd /etc/NetworkManager/system-connections/
ls -la

Check each .nmconnection file. Look for:

• Duplicate [connection] or [ipv4] sections
• Missing type= line
• Empty uuid=
• Wrong key names (use man 5 nm-settings for valid keys)

The brute-force fix: move all files to a backup dir, restart NetworkManager, then add them back one by one until it breaks again.

mkdir /tmp/backup-connections
mv *.nmconnection /tmp/backup-connections/
systemctl restart NetworkManager

If the loop stops, you found the culprit. Add files back in small batches.

3. Stale PID file blocking restart

This one's rarer but nasty. NetworkManager creates a PID file at /run/NetworkManager/NetworkManager.pid. If the service crashes hard or the system shuts down uncleanly, the PID file might stick around with a PID that's now used by another process. When systemd tries to start NetworkManager, it sees the PID file, thinks the old process is still running, and fails to start the new one. The restart loop happens because systemd keeps retrying.

I saw this on Debian 11 after a kernel panic. The PID file was left with PID 1234, which was now owned by cron. NetworkManager couldn't bind to its socket because cron wasn't NetworkManager. Systemd logged: PID file /run/NetworkManager/NetworkManager.pid not readable (yet?) after start.

Check it:

cat /run/NetworkManager/NetworkManager.pid
ps -p $(cat /run/NetworkManager/NetworkManager.pid) -o comm=

If the second command shows something like cron or bash, that's the problem. The fix:

systemctl stop NetworkManager
rm -f /run/NetworkManager/NetworkManager.pid
systemctl start NetworkManager

If the file doesn't exist but the loop continues, check /var/run/NetworkManager/NetworkManager.pid — some distros use that path.

Quick-reference summary

Start with cause #1. It's the most common. If that doesn't fix it, move to #2. Only go to #3 if the logs show nothing about DNS or connections. And don't waste time reinstalling NetworkManager unless you've exhausted these three — I've seen people reinstall the whole OS chasing this bug.