Bug 1336907 - Uninstalling NetworkManager leaves behind broken symlink at /etc/resolv.conf
Summary: Uninstalling NetworkManager leaves behind broken symlink at /etc/resolv.conf
Keywords:
Status: CLOSED DUPLICATE of bug 1367551
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 25
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-17 19:01 UTC by Robbie Harwood
Modified: 2017-02-08 11:29 UTC (History)
7 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2017-02-08 11:29:42 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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 ***


Note You need to log in before you can comment on or make changes to this bug.