Description of problem: When NetworkManager service is replaced by network service, name resolution doesn't work since /etc/resolv.conf points to non-existing /var/run/NetworkManager/resolv.conf Version-Release number of selected component (if applicable): f24, x64, xfce spin How reproducible: 100% Steps to Reproduce: 1. # systemctl stop NetworkManager 2. # systemctl disable NetworkManager 3. # systemctl start network 4. # systemctl enable network 5. $ ping google.com Actual results: ping: google.com: Name or service not known $ ll /etc/resolv.conf lrwxrwxrwx. 1 root root 35 Aug 16 13:12 /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf Expected results: name resolution works Additional info: workaround: # rm /etc/resolv.conf # touch /etc/resolv.conf # systemctl restart network
This problem still exists in Fedora 25.
when you (the administrator) changes the way how to configure networking (e.g. by disabling NetworkManager), then you also must setup DNS. that might be as simple as `rm -f /etc/resolv.conf`, but that is up to you. What do you expect NetworkManager to do here? Especially, 1) $ systemctl disable NetworkManager doesn't even invoke an action in NetworkManager. 2) $ systemctl stop NetworkManager leaves networking (and DNS) up on purpose. It doesn't do anything to resolv.conf, so that you can stop NetworkManager from remote and so that restart doesn't break connectivity. Part of the problem is that `ifup` sees the symlinked resolv.conf, and fails to replace it with a file. But how would ifup know to do that? I think this is not a bug.
Regarding 'Is it a bug or not?': Let's suppose the NetworkManager service is enabled and 'network' service is disabled. Then following sequence of commands # systemctl stop NetworkManager # systemctl start network is valid. It expresses that admin wishes to run network not managed by NetworkManager. Yet the sequence leads to a misconfigured network. Thus, for me, it looks like a bug. Regarding 'What do you expect NetworkManager to do here?': I believe that the link should be removed when the NM gives up control over system networking since from that time on it makes the configuration invalid. And that event, AFAIK, can be described as `systemctl stop NetworkManager`. So the link should be removed when NetworkManager stops (either by NetworkManager itself or by *.service `ExecStopPost=` hook) and created when NM starts. This behavior would ensure that the system won't get into misconfigured state (with exception of when NM crashes leaving the link not removed, but it's erroneous flow anyway and simple start and stop of NM should help).
(In reply to Robby from comment #1) > This problem still exists in Fedora 25. For me it also doesn't work on Fedora 25, updating Version.
(In reply to jniederm from comment #3) > Regarding 'Is it a bug or not?': > Let's suppose the NetworkManager service is enabled and 'network' service is > disabled. Then following sequence of commands > > # systemctl stop NetworkManager > # systemctl start network > > is valid. It expresses that admin wishes to run network not managed by > NetworkManager. Yet the sequence leads to a misconfigured network. Thus, for > me, it looks like a bug. > > Regarding 'What do you expect NetworkManager to do here?': > I believe that the link should be removed when the NM gives up control over > system networking since from that time on it makes the configuration > invalid. And that event, AFAIK, can be described as `systemctl stop > NetworkManager`. So the link should be removed when NetworkManager stops > (either by NetworkManager itself or by *.service `ExecStopPost=` hook) and > created when NM starts. This behavior would ensure that the system won't get > into misconfigured state (with exception of when NM crashes leaving the link > not removed, but it's erroneous flow anyway and simple start and stop of NM > should help). how about https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/dns-unsymlink-resolv-conf-rh1367551 ?
As far as I can understand it, it looks good.
> 45a2e21 dns: use nm_utils_file_is_immutable() util > f626e8c core: add nm_utils_file_is_immutable() util NAK for these two and the immutable flag check in > 71744ae dns: restore /etc/resolv.conf on NetworkManager exit from symlink We should not abuse the immutable flag to make the decision to remove a file or not. It serves a wholly different purpose than to mark the file as managed by NetworkManager. > d84015b dns: fix shutdown to restore non-cached DNS config Sounds okay.
(In reply to Thomas Haller from comment #5) > how about > https://cgit.freedesktop.org/NetworkManager/NetworkManager/log/?h=th/dns- > unsymlink-resolv-conf-rh1367551 ? Pushed a new commit. The original design was that the administrator would point /etc/resolv.conf to the private copy of a particular daemon to decide which one was in charge of updating it. In this way you could have multiple network managing daemons active and they would not interfere. With this change, the symlink is removed at every reboot and so I guess that the first daemon that starts would take ownership of resolv.conf; do you know how systemd-networkd behaves in this regard?
(In reply to Beniamino Galvani from comment #8) > (In reply to Thomas Haller from comment #5) > > The original design was that the administrator would point > /etc/resolv.conf to the private copy of a particular daemon to decide > which one was in charge of updating it. In this way you could have > multiple network managing daemons active and they would not interfere. > > With this change, the symlink is removed at every reboot and so I > guess that the first daemon that starts would take ownership of > resolv.conf; do you know how systemd-networkd behaves in this regard? what you say is true. Do you want to close this bug as NOTABUG? (fine with me). Or what is your suggestion?
*** Bug 1336907 has been marked as a duplicate of this bug. ***
*** Bug 1362173 has been marked as a duplicate of this bug. ***
The issue here is that when NetworkManager exits it cannot know if it was stopped by the admin or if this was due to host shutdown, right? So, it make sense that it should behave considering no administrator intervention happened: leave the symlink there by default. If an admin instead is configuring its own networking seems reasonable that should also take care of the symlink issue. Anyway, forcing the admin each time to fix the symlink explicitly via "rm" is a little bit rude... but doesn't we already have a nice rc-manager configuration option for NetworkManager.conf that could be set by the administrator? rc-manager=file would make him already happy I guess. jniederm? The only other "safe" option I could see is "yarv": "yet another rc-manager value", where the user can enable the symlink removal on NM stop, leveraging the branch from Thomas.
(In reply to Francesco Giudici from comment #12) > The issue here is that when NetworkManager exits it cannot know if it was > stopped by the admin or if this was due to host shutdown, right? > So, it make sense that it should behave considering no administrator > intervention happened: leave the symlink there by default. If NetworkManager creates the symlink on start, it doesn't matter why it was shut down. Just delete and recreate based on when it changes running state.
the major reason to use a symlink at all, is so that multiple services can coordinate who manages resolv.conf. If you don't want that, just configure dns=file (which is not the default configuration). If two services with NM's logic start at the same time, there would be a race who takes over resolv.conf.
(In reply to Thomas Haller from comment #14) > the major reason to use a symlink at all, is so that multiple services can > coordinate who manages resolv.conf. If you don't want that, just configure > dns=file (which is not the default configuration). What other services? > If two services with NM's logic start at the same time, there would be a > race who takes over resolv.conf. Isn't there a race there anyway because multiple services are trying to manage networking?
patch 1 from th/dns-unsymlink-resolv-conf-rh1367551 branch got merged as https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=ecd3263e4011879a960419ed04d5f526c90d55e8 I now think this needs a different solution. Please review instead https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=th/dns-unsymlink-resolv-conf-rh1367551-v2
(In reply to Thomas Haller from comment #16) > > Please review instead > https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=th/dns- > unsymlink-resolv-conf-rh1367551-v2 This seems a reasonable change to me.
merged th/dns-unsymlink-resolv-conf-rh1367551-v2 as https://cgit.freedesktop.org/NetworkManager/NetworkManager/commit/?id=15177a34be297654086005f2d796e6a4c6a1b918 . Will be part of future nm-1-8 release. dropped th/dns-unsymlink-resolv-conf-rh1367551.
So, basically now NM will no more write /etc/resolv.conf as a symlink. If rc-manager = file --> NM will always write /etc/resolv.conf as a file If rc-manager = symlink --> behavior will change from "file", only if /etc/resolv.conf is already a symlink. I wonder if we still need these two options at this point as we rely on the admin to change /etc/resolv.conf to obtain the behavior he wants from the "symlink" option. Do we really need the "file" option behavior? Patch anyway was good.
if /etc/resolv.conf is a regular file or doesn't existing, then rc-manager=file and rc-manager=symlink now both behave the same: they write a regular file. Only if /etc/resolv.conf is a symlink they behave different: - rc-manager=file will follow the symlink and write the file it points to - rc-manager=symlink will not touch the symlink -- aside from the irrelevant fact that if the symlink points to /var/run/NetworkManager/resolv.conf, then the same symlink will be recreated to emit inotify events. I still think both modes make sense.
(In reply to Francesco Giudici from comment #19) > Do we really need the "file" option behavior? I think the new symlink mode will be much better. The file mode seems only useful for distros that don't want to change behavior.
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.
Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 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.