Bug 455825

Summary: NetworkManager messes up /etc/resolv.conf even when disabled
Product: [Fedora] Fedora Reporter: Tom Lane <tgl>
Component: NetworkManagerAssignee: Dan Williams <dcbw>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: dcbw, hhorak, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-07-18 17:33:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Tom Lane 2008-07-18 02:39:28 UTC 
Description of problem:
NetworkManager overwrites /etc/resolv.conf with a nonfunctional configuration at boot,
even though it's supposedly turned off.

Version-Release number of selected component (if applicable):
NetworkManager-0.7.0-0.9.4.svn3675.fc9.x86_64

How reproducible:
100%

Steps to Reproduce:
1.  sudo /sbin/chkconfig NetworkManager off
2.  correctly configure /etc/resolv.conf
3.  reboot
4.  notice /etc/resolv.conf has been trashed.
  
Actual results:
# generated by NetworkManager, do not edit!



# No nameservers found; try putting DNS servers into your
# ifcfg files in /etc/sysconfig/network-scripts like so:
#
# DNS1=xxx.xxx.xxx.xxx
# DNS2=xxx.xxx.xxx.xxx
# SEARCH=lab.foo.com bar.foo.com

Expected results:
I'd like my configuration left alone, thank you very much.
Or at least set to what I have specified in the ifcfg-xxx files.

Additional info:
The mod timestamp on the overwritten file seems impossibly early, like before any of userland has started.
Don't tell me the kernel is invoking NetworkManager before anything else?
Comment 1 Dan Williams 2008-07-18 17:33:46 UTC 
NM will never overwrite resolv.conf if NM isn't not active.  And NM will respect
whatever you have in your ifcfg files, as long as you've told NM to manage that
device.  Since at some point you ran NetworkManager, and apparently
NetworkManager was not connected to anything when you shut down, your
resolv.conf is no longer valid.

The problem here is that resolv.conf is not static.  When you connect to a VPN,
you want that VPN's nameservers merged into your resolv.conf, otherwise it would
be pointless to connect to the VPN.  But you don't want those VPN nameservers
present when you're not connected to the VPN, otherwise you won't be able to
resolve anything.  _Something_ needs to modify resolv.conf and update it with
the correct DNS information.  If the system-config-network scripts kept a
canonical copy of the resolv.conf file somewhere, we could make NetworkManager
restore that copy when it shuts down.  But as long as /etc/resolv.conf is the
only canonical source for DNS information, there's not much you can do when you
have to update it with new info.

So in short, NM isn't messing up resolv.conf when it's not running.  It's
because you turned NM off that your resolv.conf isn't getting updated any more.
 When you change your network configuration (such as turning NM off) you'll also
need to make sure your resolv.conf is correct.
Comment 2 Tom Lane 2008-07-18 20:02:25 UTC 
I did *not* run NM, at least not intentionally, and I can't find any part of the system startup scripts that 
invoked it either.  If you can tell me where to deactivate it so it stays deactivated, I'd be happy.