Bug 436647 - resolv.conf loses name servers after upgrade
resolv.conf loses name servers after upgrade
Product: Fedora
Classification: Fedora
Component: bind (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Adam Tkac
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-08 14:45 EST by Ray Todd Stevens
Modified: 2013-04-30 19:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-03-13 13:18:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Ray Todd Stevens 2008-03-08 14:45:01 EST
I upgraded my server running raw hide.   (This server is actually used at about
the rate of a production server, but for testing and personal purposes so I
switched it in order to get a better picture of this software)

Anyway everything was running hunky dorry on this part, and then all network
names stopped resolving.   A quick look at the resolv.conf showed why.   I
originally had to name server and one search statements in it.   One fo the name
servers (the first)  is the localhost, as we are running a name server
on this server.  The other name server is a seperate local name server in case
the name server process dies.   Then I had a search statement for our local domains.

As I said quick look at the resolv.conf showed the problem.   The search
statement was still there, but the name server statements were gone.   Some
automated process appears to have done this, as I didn't manually edit it to do
Comment 1 Adam Tkac 2008-03-10 07:09:18 EDT
I don't think this is related to bind. Are you using NetworkManager? Is network
interface configured statically or you get IP from dhcp? Those two utilities can
modify resolv.conf I think.
Comment 2 Ray Todd Stevens 2008-03-10 12:43:26 EDT
I have fixed this at my site. Frankly it it was not a rawhide issue, I would not
have filed a report.  I only experienced this on one station of the three I am
running various tests of rawhide (IE fc9alpha) on.   Since this is an alpha I
figure you need to not only hear about the solid failures which is the klind of
thing I report for production releases, but at least you need to be made aware
of the flaky problems.   Maybe for rawhide bug reports a "I am reporting this in
case you need people experiencing this problem, but I don't really expect you to
do any more than take notice of it unless a bunch of people experience this
error. Then I would be glad to help debug it" status.

As for your other questions

Network manager.  I am not sure what you are asking here.  I do user
"administration - Network" to modify my network settings, but did not use this
between when it was last working and when I did the update.   In order to do the
update I would assume that the name servers would have to have been working.   I
found the problem a little while after the last update (maybe 3 hours).

We are not running dchp on this system.   Both the client and server software
are loaded on this machine to be used as a part of failure recovery, but it is
not configured.   The server is at a rcx.d K status (I checked) and none of the
interfaces are currently programmed for dhcp.   I thought of this and checked that.

I maybe should have mentioned running an update shortly before the problem was

Comment 3 Adam Tkac 2008-03-12 13:59:22 EDT
(In reply to comment #2)
> Network manager.  I am not sure what you are asking here.  I do user
> "administration - Network" to modify my network settings, but did not use this
> between when it was last working and when I did the update.

NetworkManager is service. You can check if you're using it with $ chkconfig
--list NetworkManager (or with $service NetworkManager status). If you have this
service running it might modify your resolv.conf . This change is definitely not
caused by bind package because bind is name server (not resolver) and does
nothing with resolv.conf (resolvers use this file to find IP of nameserver)
Comment 4 Ray Todd Stevens 2008-03-12 15:09:27 EDT
Not running this.

I think your comment on it not actually being bind might be on target.  
However, it is frequently hard for an outsider to figure out which component is
at fault.

It has not happened any more.  Does make one wonder.
Comment 5 Adam Tkac 2008-03-13 13:18:30 EDT
It's nearly impossible find what component broke your resolv.conf without more
info. If it happen again try collect more information and reopen this one,
please. Closing for now
Comment 6 Ray Todd Stevens 2008-03-13 13:45:04 EDT
I tend to agree.   

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