Bug 216796 - automount has no method to re-read resolver settings (resolv.conf)
automount has no method to re-read resolver settings (resolv.conf)
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: autofs (Show other bugs)
4.4
All Linux
medium Severity low
: ---
: ---
Assigned To: Jeff Moyer
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-21 19:47 EST by Eric Berggren
Modified: 2008-01-08 11:48 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-08 11:48:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to automount.c which (naively) runs res_init() at map (re)read (assumes DNS employed) (545 bytes, patch)
2006-11-21 19:47 EST, Eric Berggren
no flags Details | Diff

  None (edit)
Description Eric Berggren 2006-11-21 19:47:13 EST
Description of problem:

There is no way to make automount reread /etc/resolv.conf values short of
restarting it. At least a -HUP signal should facilitate this.

Version-Release number of selected component (if applicable):

ALL (autofs-4.1.3-187)

Steps to Reproduce:
1. Update /etc/resolv.conf with new name server records (or from dhcp release)
2. Reload/restart nscd
3. pkill -HUP automount
  
Actual results:

automount processes still use old name server(s), even after -HUPing as
confirmed by strace

Expected results:

Changes to DNS resolver (commonly in use) ought to be realized, at least upon
signalling where restarting is not possible.

Additional info:

Restarting automount jobs require unmounting all managed filesystems, which
often isn't possible in distributed environments.
Comment 1 Eric Berggren 2006-11-21 19:47:13 EST
Created attachment 141856 [details]
Patch to automount.c which (naively) runs res_init() at map (re)read (assumes DNS employed)
Comment 2 Jeff Moyer 2006-11-27 17:17:48 EST
This seems like a reasonable approach to me.  Did you test it?
Comment 3 Ian Kent 2006-11-27 22:16:24 EST
(In reply to comment #2)
> This seems like a reasonable approach to me.  Did you test it?

Seems sensible to me as well.
I'll put this on the list for v5 as well.

Ian
Comment 4 Eric Berggren 2006-11-28 14:24:53 EST
Only thought would be whether this would affect autofs users not using DNS, as
this now pulls in libresolv directly instead of relying on nss via libc.

Otherwise seems to work for us.

-ericb
Comment 5 Jeff Moyer 2006-11-28 14:43:15 EST
OK, so this needs to be tested in an environment that uses nis for hostname lookups.
Comment 7 Jeff Moyer 2007-01-17 11:36:10 EST
This is fixed in package version autofs-4.1.3-205.
Comment 8 RHEL Product and Program Management 2007-05-09 04:51:04 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 10 Jeff Moyer 2007-07-16 15:27:28 EDT
Eric,

I cannot reproduce the problem that was reported by you.  Can you give more
specific information about your test configuration?  Here is what I did:

create /etc/resolv.conf with a single name server entry:

server 10.12.32.11

Start the automounter with a single map for /test, /etc/auto.test:
foo  segfault:/export/foo
bar  moe.lab:/export/bar

ls /test/foo succeeds as expected.  Then, I change the server line in
resolv.conf to:

server 10.12.32.10

and I drop all packets destined for the old server

iptables -A OUTPUT -d 10.12.32.11 -j DROP

And I trigger another lookup, and it succeeds.  So, how exactly did you get this
to fail?
Comment 11 Jeff Moyer 2007-08-02 14:16:20 EDT
Eric, I'm going to have to remove this change given that I can't reproduce the
problem.
Comment 12 Suzanne Yeghiayan 2007-09-17 15:58:30 EDT
This request was previously evaluated by Red Hat Product Management
for inclusion in the current Red Hat Enterprise Linux release, but
Red Hat was unable to resolve it in time.  This request will be
reviewed for a future Red Hat Enterprise Linux release.
Comment 13 RHEL Product and Program Management 2007-11-28 23:23:11 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 14 Jeff Moyer 2008-01-02 11:27:33 EST
I'm still waiting for a reproducer.  Unless one is provided, I'm going to close
this bug WONTFIX.
Comment 15 Jeff Moyer 2008-01-08 11:48:33 EST
Given that I can't reproduce the problem and there's been no response from the
reporter for some time, I'm closing this bugzilla.

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