Bug 216796

Summary: automount has no method to re-read resolver settings (resolv.conf)
Product: Red Hat Enterprise Linux 4 Reporter: Eric Berggren <ericb>
Component: autofsAssignee: Jeff Moyer <jmoyer>
Status: CLOSED WONTFIX QA Contact: Brock Organ <borgan>
Severity: low Docs Contact:
Priority: medium    
Version: 4.4CC: ikent
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-08 16:48:33 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:
Attachments:
Description Flags
Patch to automount.c which (naively) runs res_init() at map (re)read (assumes DNS employed) none

Description Eric Berggren 2006-11-22 00:47:13 UTC
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-22 00:47:13 UTC
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 22:17:48 UTC
This seems like a reasonable approach to me.  Did you test it?

Comment 3 Ian Kent 2006-11-28 03:16:24 UTC
(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 19:24:53 UTC
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 19:43:15 UTC
OK, so this needs to be tested in an environment that uses nis for hostname lookups.

Comment 7 Jeff Moyer 2007-01-17 16:36:10 UTC
This is fixed in package version autofs-4.1.3-205.

Comment 8 RHEL Program Management 2007-05-09 08:51:04 UTC
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 19:27:28 UTC
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 18:16:20 UTC
Eric, I'm going to have to remove this change given that I can't reproduce the
problem.

Comment 12 Suzanne Logcher 2007-09-17 19:58:30 UTC
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 Program Management 2007-11-29 04:23:11 UTC
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 16:27:33 UTC
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 16:48:33 UTC
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.