Bug 1336907

Summary:	Uninstalling NetworkManager leaves behind broken symlink at /etc/resolv.conf
Product:	[Fedora] Fedora	Reporter:	Robbie Harwood <rharwood>
Component:	NetworkManager	Assignee:	Lubomir Rintel <lkundrak>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	25	CC:	amcnabb, dcbw, fgiudici, lkundrak, nphilipp, psimerda, thaller
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-02-08 11:29:42 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Robbie Harwood 2016-05-17 19:01:37 UTC

After installing the f24 beta, and uninstalling NetworkManager, resolv.conf is left in a busted state.  This seems unintentional:

# file /etc/resolv.conf
/etc/resolv.conf: broken symbolic link to /var/run/NetworkManager/resolv.conf

Comment 1 Thomas Haller 2016-10-21 15:35:57 UTC

When stopping NetworkManager, interfaces are left up. Likewise, the symbolic link /etc/resolv.conf is not changed.
This allows you to restart NetworkManager without loosing connectivity.




you encounter the same issue if you do:

  systemctl mask NetworkManager && reboot
  # ups, nobody took over resolv.conf and it points to nowhere.


So I don't think that the answer to this bug is that RPM should reset resolv.conf on package removal.
Also, I don't see how NetworkManager.rpm could mangle /etc/resolv.conf on package removal, because RPM wouldn't know which better DNS configuration to use instead. An empty resolv.conf isn't useful either.
Also, mangle /etc/resolv.conf on package removal breaks:

  systemctl stop NetworkManager
  # still connected
  dnf remove NetworkManager
  # ups, RPM broke resolv.conf
  systemctl start other-networking-daemon.service
  # resolv.conf is good again.
  # Or at least, it's up to other-networking-daemon.





If you stop NetworkManager for good and want to uninstall it, it is up to you to configure your network and resolv.conf (or setup another component to do that).




I don't see how this could be fixed.

Comment 2 Robbie Harwood 2016-10-21 17:29:54 UTC

I did.  I set up network (chkconfig network on) and rebooted.  After which the symlink is still broken.

Comment 3 Andrew McNabb 2016-12-03 01:19:33 UTC

In the case where the sysinit network scripts are enabled, they could fix the /etc/resolv.conf file if it's a broken symlink.

One simple change would work at least in the case where DNS1 or DNS2 are set in the configuration. This change would be to modify /etc/sysconfig/network-scripts/ifup-post to replace a broken symbolic link with an empty file around line 77, where it currently backs up resolv.conf. For example:

# backup resolv.conf
cp -af /etc/resolv.conf /etc/resolv.conf.save

# replace a broken symbolic link with an empty file
if [ -h /etc/resolv.conf -a ! -e /etc/resolv.conf ]; then
  rm -f /etc/resolv.conf
  touch /etc/resolv.conf
fi

If NetworkManager creates a backup of /etc/resolv.conf when it overwrites it with a symlink, then perhaps this could be extended to attempt to restore the backup, but I personally believe the above fix is safer.

Anyway, I would love to see this fix to /etc/sysconfig/network-scripts-ifup-post.

Comment 4 Andrew McNabb 2016-12-03 01:28:45 UTC

I just created bug 1401154 in the initscripts component to describe this workaround.

Comment 5 Nils Philippsen 2016-12-08 13:19:51 UTC

What's this got to do with system-config-network?

Comment 6 Andrew McNabb 2016-12-19 14:03:32 UTC

Nils, it shouldn't be assigned to system-config-network. Sorry for that!

Comment 7 Thomas Haller 2016-12-19 15:18:26 UTC

For now, I am closing this as NOTABUG.

It just means, if you change your networking configuration, you can end up with broken resolv.conf if you do it wrong.
If you mess up your networking configuration, all kind of things can happen.
It's unclear to me what NetworkManager should do to prevent that.

If a user does:

  $ systemctl mask NetworkManager
  $ reboot

the same issue happens. But NetworkManager isn't even aware that it's going to be disabled on reboot. And the NetworkManager RPM was not removed either.

It's really just user configuration. The user must configure a replacement for NetworkManager. Whatever that means in detail is up to the user.




If you have a *concrete* suggestion what NetworkManager should do, please reopen.


Thanks.

Comment 8 Robbie Harwood 2016-12-19 18:24:30 UTC

The following are sufficient to trigger this issue:

    # dnf erase NetworkManager
    # chkconfig network on
    # reboot

To my view, I have just configured a replacement: network.  Network relies on this symlink not being dead - that is, it wants to write to a file accessible by pathname /etc/resolv.conf, which is normal.

In the worst case, on removal, NetworkManager should absolutely fix this symlink.  The error cases from not fixing this symlink are utterly unintuitive as well; no one expects a broken symlink there.  If you prefer this to be worked around in network or initscripts that's fine with me too, but right now every component says they can't fix it, and so the bug remains.

Comment 9 Andrew McNabb 2016-12-20 00:45:02 UTC

Agreed. There should be some approved way to disable NetworkManager that results in a working system.

Comment 10 Thomas Haller 2017-02-08 11:29:42 UTC

marking this as duplicate. Please follow up at bug 1367551

*** This bug has been marked as a duplicate of bug 1367551 ***