Bug 323181 - automount lookups fail with ENOENT
automount lookups fail with ENOENT
Status: CLOSED DUPLICATE of bug 354621
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
low Severity low
: ---
: ---
Assigned To: Jeffrey Moyer
Martin Jenner
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-08 11:22 EDT by Jeffrey Moyer
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-02 12:46:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Jeffrey Moyer 2007-10-08 11:22:30 EDT
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 Jeffrey Moyer 2007-10-08 11:22:30 EDT
Created attachment 219821 [details]
debug log from the automounter
Comment 2 Jeffrey Moyer 2007-11-02 12:46:30 EDT

*** This bug has been marked as a duplicate of 345621 ***
Comment 3 Jeffrey Moyer 2007-11-02 12:57:28 EDT

*** 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.