Red Hat Bugzilla – Bug 436647
resolv.conf loses name servers after upgrade
Last modified: 2013-04-30 19:38:46 EDT
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, 127.0.0.1 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
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.
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
(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)
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
It has not happened any more. Does make one wonder.
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
I tend to agree.