Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1367551 - When NetworkManager service is disabled, /etc/resolv.conf becomes a broken link
Summary: When NetworkManager service is disabled, /etc/resolv.conf becomes a broken link
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Lubomir Rintel
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1336907 1362173 (view as bug list)
Depends On:
Blocks: 1423490
TreeView+ depends on / blocked
 
Reported: 2016-08-16 18:14 UTC by jniederm
Modified: 2017-12-12 10:25 UTC (History)
9 users (show)

Fixed In Version: NetworkManager-1.8.0-0.2.git20170215.1d40c5f4.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1423490 (view as bug list)
Environment:
Last Closed: 2017-12-12 10:25:53 UTC


Attachments (Terms of Use)

Description jniederm 2016-08-16 18:14:11 UTC
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

Comment 1 Robby 2016-11-28 02:05:11 UTC
This problem still exists in Fedora 25.

Comment 2 Thomas Haller 2016-11-28 10:11:19 UTC
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.

Comment 3 jniederm 2017-02-04 10:14:59 UTC
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).

Comment 4 jniederm 2017-02-04 10:18:42 UTC
(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.

Comment 5 Thomas Haller 2017-02-04 20:36:47 UTC
(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 ?

Comment 6 jniederm 2017-02-06 12:04:39 UTC
As far as I can understand it, it looks good.

Comment 7 Lubomir Rintel 2017-02-08 10:19:14 UTC
> 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.

Comment 8 Beniamino Galvani 2017-02-08 10:47:54 UTC
(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?

Comment 9 Thomas Haller 2017-02-08 11:21:42 UTC
(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?

Comment 10 Thomas Haller 2017-02-08 11:29:42 UTC
*** Bug 1336907 has been marked as a duplicate of this bug. ***

Comment 11 Thomas Haller 2017-02-08 11:30:06 UTC
*** Bug 1362173 has been marked as a duplicate of this bug. ***

Comment 12 Francesco Giudici 2017-02-09 17:37:42 UTC
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.

Comment 13 Robbie Harwood 2017-02-09 18:18:55 UTC
(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.

Comment 14 Thomas Haller 2017-02-09 18:42:18 UTC
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.

Comment 15 Robbie Harwood 2017-02-09 19:10:34 UTC
(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?

Comment 16 Thomas Haller 2017-02-10 18:22:43 UTC
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

Comment 17 Beniamino Galvani 2017-02-14 14:47:06 UTC
(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.

Comment 18 Thomas Haller 2017-02-14 17:34:32 UTC
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.

Comment 19 Francesco Giudici 2017-02-14 18:05:53 UTC
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.

Comment 20 Thomas Haller 2017-02-14 20:01:29 UTC
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.

Comment 21 Thomas Haller 2017-02-14 20:05:25 UTC
(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.

Comment 22 Fedora End Of Life 2017-11-16 19:43:43 UTC
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.

Comment 23 Fedora End Of Life 2017-12-12 10:25:53 UTC
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.


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