Bug 163173

Summary: Boot hangs 'Mounting NFS filesystems' with nss_ldap for hosts
Product: Red Hat Enterprise Linux 4 Reporter: Kevin Collins <kcollins>
Component: nss_ldapAssignee: Nalin Dahyabhai <nalin>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: jakub, jplans, kzak, steved
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 16:15:25 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:

Description Kevin Collins 2005-07-13 18:21:25 UTC
Description of problem:

My system is configured to use LDAP. If I have the netfs rc script enabled 
(chkconfig netfs on) and there are NFS mounts specified in /etc/fstab, the 
system will hang at "Mounting NFS filesystems" during boot.

In addition, if I disable netfs and then boot, the mount will hang when I 
run "service netfs start", or if I manually attempt to mount the NFS 
filesystem.

I _only_ see this problem when nsswitch is using ldap for hosts lookups. If I 
create a local host file entry for the NFS server(s) or put dns ahead of ldap 
in the search order, the problem does not occur. However, in my environment, I 
need to have ldap before dns.

Running strace on the mount command, it hangs with:

futex(0xa1d174, FUTEX_WAIT, 2, NULL

If I Ctrl-C, the mount command is interrupted. Sometimes, the filesystem has 
mounted but most times not.

I found a very similar bug with lots of dupes in RH9 with smbfs 
(https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90036)

If I "export LD_ASSUME_KERNEL=2.4.1" (described in the bug/dupes) the mount 
command succeeds, so this seems to be the same basic problem.

My nsswitch.conf has the following entry:

hosts:      files ldap dns

/etc/ldap.conf has (grep -v ^# /etc/ldap.conf):

host 146.27.78.210 146.27.78.209
base dc=afis,dc=sr
port 389
ssl no
pam_password crypt

/etc/hosts has: 

127.0.0.1       localhost localhost.localdomain loopback
146.28.34.30    cpafisxy xy
146.27.78.210   cpafisxc xc
146.27.78.209   cpafisxb xb


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


How reproducible:

Every Time

Steps to Reproduce:
1. Configure system to use ldap for host lookups
2. make sure nscd is NOT running
3. attempt an NFS mount command
  
Actual results:

mount command hangs

Expected results:

mount command should return

Additional info:

strace mount -t nfs cpafisc4:/util/bin /util/bin -o tcp,nfsvers=3
...
...
geteuid32()                             = 0
open("/etc/ldap.conf", O_RDONLY)        = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=8701, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7fff000
read(3, "# @(#)$Id: ldap.conf,v 1.34 2004"..., 4096) = 4096
read(3, "d change\n# extended operation to"..., 4096) = 4096
read(3, "\n#tls_ciphers TLSv1\n\n# Client ce"..., 4096) = 509
read(3, "", 4096)                       = 0
close(3)                                = 0
munmap(0xb7fff000, 4096)                = 0
uname({sys="Linux", node="cpafisxy", ...}) = 0
futex(0xa1d174, FUTEX_WAIT, 2, NULL

Comment 1 Steve Dickson 2005-09-01 12:10:50 UTC
Is this a nfs-utils problem or a glibc problem since the nfs-utils
daemon simple use the gethostbyXXX() routines to resolve
host names?

Comment 2 Jakub Jelinek 2005-09-01 12:17:00 UTC
Likely nss_ldap problem (separate package).

Comment 4 Jiri Pallich 2012-06-20 16:15:25 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.