Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 163173 - Boot hangs 'Mounting NFS filesystems' with nss_ldap for hosts
Summary: Boot hangs 'Mounting NFS filesystems' with nss_ldap for hosts
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: nss_ldap
Version: 4.0
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Nalin Dahyabhai
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-07-13 18:21 UTC by Kevin Collins
Modified: 2012-06-20 16:15 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 16:15:25 UTC


Attachments (Terms of Use)

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.


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