After disabling NetworkManager, /etc/resolv.conf is a broken symbolic link: # file /etc/resolv.conf /etc/resolv.conf: broken symbolic link to /var/run/NetworkManager/resolv.conf In b/1336907, Thomas Haller said that NetworkManager cannot fix this because it needs to leave its symlink available when turning off in order to allow you to restart NetworkManager without losing connectivity. One simple change in the sysinit scripts 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.
Sorry for the broken link. I should have pointed at bug 1336907.
Pff, that's a tough nut to crack. I don't think adding hacky workarounds in different network managers (NetworkManager, initscripts, systemd-resolved, …) is going to work. We (systemd) think that the /etc/resolv.conf symlink is admin territory, and should not be changed by the different network managers, because they don't know what is intent of the administrator. The only exception is that if no link exists, we assume it's OK to create the symlink, to provide connectivity. In particular, during system boot, it's possible for different network managers to start in parallel, and they cannot tell if a dangling symlink means that the service that will create the file that the symlink points at hasn't started yet, or that it will not start at all.
Zbigniew, I agree that it's a messy situation. Various network managers have been overwriting the /etc/resolv.conf file for a long time, and NetworkManager is currently replacing the /etc/resolv.conf file with a symlink regardless of system administrator approval. My understanding was that systemd had pushed for this (to avoid having files in /etc modified at each boot), and this change doesn't seem to have accounted for any way for system administrators to disable NetworkManager and get a working network.service setup. In the current system, moving from NetworkManager.service to network.service results in a non-working network configuration. I personally feel that it's better to have undefined behavior if different network managers start in parallel than to have undefined behavior if NetworkManager.service is disabled and network.service is enabled. If network.service can't be changed to cleanup a broken symlink, then could NetworkManager instead be changed to not replace the file with a symlink in the first place?
I agree with Zbigniew. This is something initscripts should not do. We don't know if NM or some other network service will be started five seconds after us.
In this case, I think the only other solution may be for NetworkManager to stop replacing resolv.conf with a symlink.
This message is a reminder that Fedora 25 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 25. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '25'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 25 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.