Bug 323181 - automount lookups fail with ENOENT
Summary: automount lookups fail with ENOENT
Keywords:
Status: CLOSED DUPLICATE of bug 354621
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
low
low
Target Milestone: ---
: ---
Assignee: Jeff Moyer
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-08 15:22 UTC by Jeff Moyer
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-11-02 16:46:30 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
debug log from the automounter (18.29 KB, text/plain)
2007-10-08 15:22 UTC, Jeff Moyer
no flags Details

Description Jeff Moyer 2007-10-08 15:22:30 UTC
Description of problem:
Thanks very much. I have reproduced the problem and have a debug log.
Interestingly, I could not reproduce it with a file map, but could with an ldap
map. However, that may be a red herring (see below).

I don't see any obvious differences in the debug log below between
the good case and the bad case (ENOENT), but perhaps I've missed something.

As you can see below in the behavior section, the first time catting the file
works for both the file map and the ldap map.
The second time for the ldap map is when I get the ENOENT. It's as if the kernel
thinks the directory (u10, in this case) is still there, but has nothing in it,
even though it has been previously umounted. I'm not sure if it is the automount
daemon that is at fault, as it seems to be doing the same thing in both cases.

If it's an unintentional race condition between the kernel and the automount
daemon, perhaps the ldap lookup delay causes the race to be revealed, and so
maybe the problem is not ldap per se.

Another odd note:
I -have- reproduced the ENOENT with a file map and starting /usr/sbin/automount
by hand with appropriate arguments. However, I had to have done "service start
automount"
beforehand, so there were a number of other automount daemons running (which
used ldap).
If I started a /usr/sbin/automount by hand after "service stop automount", with no
other automount daemons running, I cannot reproduce the problem.

To repeat something from my previous message, I don't see the problem with
autofs-5.0.1-0.rc2.43.0.2 on an CentOS 5 system.

Thanks,
Dan

-----------------------------------------------------------------------------

This is the behavior I see:

   ##### Start automount fresh.
   # service autofs start
   Starting automount:                                        [  OK  ]

   ##### cat a file reachable via automount with a file map. That works fine.
   # cat /mnt-via-file/u10/test
   Contents of test.

   ##### Umount and try again. Works fine.
   # umount /mnt-via-file/u10
   # cat /mnt-via-file/u10/test
   Contents of test.
   # umount /mnt-via-file/u10

   ##### Now try the same thing with an ldap map. The first time, it works.
   # cat /mnt-via-ldap/u10/test
   Contents of test.

   ##### Unmount and try again. The second time
   ##### cat does not see the file (ENOENT)!   *********
   # umount /mnt-via-ldap/u10
   # cat /mnt-via-ldap/u10/test
   cat: /mnt-via-ldap/u10/test: No such file or directory

   ##### Try again, and the file is now there.
   # cat /mnt-via-ldap/u10/test
   Contents of test.

----------------------------------------------------------------------
autofs version:
	autofs-4.1.3-199.3
(I also reproduced the problem with autofs-4.1.3-214, the latest version
  at jmoyer's webpage.)
----------------------------------------------------------------------
kernel:
	2.6.9-55.0.9.ELsmp x86_64
----------------------------------------------------------------------
/etc/auto.master (comments removed):

/mnt-via-file /etc/auto.mnt -rw,hard,intr --ghost --timeout=3333 --debug
/mnt-via-ldap ldap:ou=auto.podraid2,ou=autofs,dc=podzinger,dc=local
-rw,hard,intr --ghost --timeout=4444 --debug
----------------------------------------------------------------------
/etc/auto.mnt (referenced in auto.master above). It's meant to be
the same as the ldap map below.

*       podraid2.podzinger.local:/export/&
----------------------------------------------------------------------
auto.podraid2 map from ldap (in LDIF format):

dn: cn=*,ou=auto.podraid2,ou=autofs,dc=podzinger,dc=local
cn: *
objectClass: automount
automountInformation: podraid2.podzinger.local:/export/&
----------------------------------------------------------------------
/etc/nsswitch.conf (comments and blank lines removed):

passwd:     files ldap
shadow:     files ldap
group:      files ldap
hosts:      files dns
bootparams: files
ethers:     files
netmasks:   files
networks:   files
protocols:  files ldap
rpc:        files
services:   files ldap
netgroup:   files ldap
publickey:  files
automount:  files ldap
aliases:    files
----------------------------------------------------------------------
/etc/sysconfig/autofs (comments removed):
(we have not modified this):

LOCALOPTIONS=""
DAEMONOPTIONS="--timeout=60"
LDAPAUTOMASTER=""
UNDERSCORETODOT=1
DISABLE_DIRECT=1
ONE_AUTO_MASTER=0
GHOSTDIRS=""
BASEDN=
OLD_LDAP_LOOKUP=0
----------------------------------------------------------------------

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

How reproducible:
100%

Comment 1 Jeff Moyer 2007-10-08 15:22:30 UTC
Created attachment 219821 [details]
debug log from the automounter

Comment 2 Jeff Moyer 2007-11-02 16:46:30 UTC

*** This bug has been marked as a duplicate of 345621 ***

Comment 3 Jeff Moyer 2007-11-02 16:57:28 UTC

*** This bug has been marked as a duplicate of 354621 ***


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