Bug 436647 - resolv.conf loses name servers after upgrade
Summary: resolv.conf loses name servers after upgrade
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: bind
Version: rawhide
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Adam Tkac
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-03-08 19:45 UTC by Ray Todd Stevens
Modified: 2013-04-30 23:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-03-13 17:18:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Ray Todd Stevens 2008-03-08 19:45:01 UTC
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
this.

Comment 1 Adam Tkac 2008-03-10 11:09:18 UTC
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 16:43:26 UTC
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
discovered.



Comment 3 Adam Tkac 2008-03-12 17:59:22 UTC
(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 19:09:27 UTC
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 17:18:30 UTC
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 17:45:04 UTC
I tend to agree.   


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