Bug 304111 - Autofs fails to match wildcard
Autofs fails to match wildcard
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: autofs (Show other bugs)
5.0
All Linux
low Severity high
: ---
: ---
Assigned To: Ian Kent
Brock Organ
: Regression
: 431918 (view as bug list)
Depends On:
Blocks: 354621
  Show dependency treegraph
 
Reported: 2007-09-24 17:29 EDT by Jeffrey Moyer
Modified: 2008-03-13 03:17 EDT (History)
8 users (show)

See Also:
Fixed In Version: RHBA-2007-0621
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-11-07 12:56:19 EST
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 of service autofs start; ls /home/boston/jburke; service autofs stop (6.05 KB, text/plain)
2007-09-24 17:29 EDT, Jeffrey Moyer
no flags Details
Correct mistake in logic test in wildcard lookup. (2.03 KB, patch)
2007-09-25 00:10 EDT, Ian Kent
no flags Details | Diff

  None (edit)
Description Jeffrey Moyer 2007-09-24 17:29:52 EDT
Description of problem:

auto.master:
/home  /etc/auto.accounts

/etc/auto.accounts:
* -rw,nosymlink,rsize=8192,wsize=8192,hard,intr file:/vol/data/home/&

[root@barron ~]# service autofs start
Starting automount:                                        [  OK  ]
[root@barron ~]# ls /home/boston/jburke
ls: /home/boston/jburke: No such file or directory
[root@barron ~]# mount | grep boston
file:/vol/data/home/boston on /home/boston type nfs
(rw,rsize=8192,wsize=8192,hard,intr,addr=172.16.76.17)

So, /home/boston was mounted, but a failure was returned to ls!  This affects X
logins, such that you cannot even login.  Here is a snippet of the debug log:

Sep 24 17:23:18 barron automount[3845]: lookup_mount: lookup(file): check
indirect map lookup failed
Sep 24 17:23:18 barron automount[3845]: send_fail: token = 25
Sep 24 17:23:18 barron automount[3845]: failed to mount /home/boston
Sep 24 17:23:18 barron automount[3845]: handle_packet: type = 3
Sep 24 17:23:18 barron automount[3845]: handle_packet_missing_indirect: token
26, name boston, request pid 3855
Sep 24 17:23:18 barron automount[3845]: attempting to mount entry /home/boston
Sep 24 17:23:18 barron automount[3845]: lookup_mount: lookup(file): looking up
boston
Sep 24 17:23:18 barron automount[3845]: lookup_mount: lookup(file): boston ->
-rw,nosymlink,rsize=8192,wsize=8192,hard,intr file:/vol/data/home/&
Sep 24 17:23:18 barron automount[3845]: parse_mount: parse(sun): expanded entry:
-rw,nosymlink,rsize=8192,wsize=8192,hard,intr file:/vol/data/home/boston
Sep 24 17:23:18 barron automount[3845]: parse_mount: parse(sun): gathered
options: rw,nosymlink,rsize=8192,wsize=8192,hard,intr
Sep 24 17:23:18 barron automount[3845]: parse_mount: parse(sun):
dequote("file:/vol/data/home/boston") -> file:/vol/data/home/boston
Sep 24 17:23:18 barron automount[3845]: parse_mount: parse(sun): core of entry:
options=rw,nosymlink,rsize=8192,wsize=8192,hard,intr, loc=file:/vol/data/home/boston
Sep 24 17:23:18 barron automount[3845]: sun_mount: parse(sun): mounting root
/home, mountpoint boston, what file:/vol/data/home/boston, fstype nfs, options
rw,nosymlink,rsize=8192,wsize=8192,hard,intr
Sep 24 17:23:18 barron automount[3845]: mount_mount: mount(nfs): root=/home
name=boston what=file:/vol/data/home/boston, fstype=nfs,
options=rw,nosymlink,rsize=8192,wsize=8192,hard,intr
Sep 24 17:23:18 barron automount[3845]: mount_mount: mount(nfs): nfs
options="rw,rsize=8192,wsize=8192,hard,intr", nosymlink=1, ro=0
Sep 24 17:23:18 barron automount[3845]: mount_mount: mount(nfs): calling
mkdir_path /home/boston
Sep 24 17:23:18 barron automount[3845]: mount_mount: mount(nfs): calling mount
-t nfs -s -o rw,rsize=8192,wsize=8192,hard,intr file:/vol/data/home/boston
/home/boston
Sep 24 17:23:18 barron automount[3845]: mount(nfs): mounted
file:/vol/data/home/boston on /home/boston
Sep 24 17:23:18 barron automount[3845]: send_ready: token = 26

the nsswitch.conf line reads:
automount: files nis

Version-Release number of selected component (if applicable):
autofs-5.0.1-rc2.54

How reproducible:
100%
Comment 1 Jeffrey Moyer 2007-09-24 17:29:52 EDT
Created attachment 204591 [details]
debug log of service autofs start; ls /home/boston/jburke; service autofs stop
Comment 2 Ian Kent 2007-09-25 00:06:05 EDT
Yep, seen that.
Have duplicated it.
Has already been fixed.
Seems I missed it for 5.1, oops.
Will fix in 5.2.

Ian
Comment 3 Ian Kent 2007-09-25 00:10:58 EDT
Created attachment 204811 [details]
Correct mistake in logic test in wildcard lookup.

Thanks for alerting me to this.
It's getting harder to correlate between what has and
hasn't been fixed as the number of corrections increases
between versions.

Could you verify that this patch also works for you
please.

Ian
Comment 4 Jeff Burke 2007-09-25 08:29:09 EDT
Ian,
    This is big regression from 5.0 GA. In my opinion this can not go out the
door like this. The user experience is very bad.

Here was my scenario:
I was running fine on RHEL5.0, I used yum to ugrade to 5.1 Snapshot#8, rebooted
then I could no longer login via X. I would get a message box telling me that my
home dir could not be mounted, would I like to use / as my home dir.

Thanks,
Jeff

Comment 5 RHEL Product and Program Management 2007-09-25 08:44:25 EDT
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.
Comment 6 James Laska 2007-09-25 08:49:18 EDT
The failure scenario seems fairly common (at least in our internal RH setup).  I
think it would be worth discussing taking this fix for 5.1.  

Some things to help that decision:

 - What use cases fail given the current state of code?
 - Is this the final patch?  Is it a temporary fix?
 - Has the patch been tested?
 - Will this change impact any related changes noted in the 5.1 autofs errata
(http://errata.devel.redhat.com/errata/show/5789)?
Comment 7 Ian Kent 2007-09-25 09:44:01 EDT
(In reply to comment #6)
> The failure scenario seems fairly common (at least in our internal RH setup).  I
> think it would be worth discussing taking this fix for 5.1.  

Agreed, I'm at a loss as to why I don't have a bug for this.
It was fixed Jun 3 which was within the development window.
It was introduced by me in the patch for bug 238533. This
is one of my 5.1 approved bugs and so should be covered as
a correction to that bug.

> 
> Some things to help that decision:
> 
>  - What use cases fail given the current state of code?

The error will cause autofs to incorrectly request a map
update and return a lookup failure when the lookup returns
a key missing status from the internal cache. The cache key
missing status is quite common as keys are learned during
normal execution.

>  - Is this the final patch?  Is it a temporary fix?
>  - Has the patch been tested?

Yes and yes, it's been in use in Fedora (and devel) since
Jun 3 without issue.

Inspection of the patch shows that it's basically a typing
error and so I quite reasonably expect it will be a safe
change.

>  - Will this change impact any related changes noted in the 5.1 autofs errata
> (http://errata.devel.redhat.com/errata/show/5789)?

I can't see any bugs in the errata that would be effected
by this change, except for 238533, for which which we would
need to add an explicit test for this as part of a retest.

Ian
Comment 14 errata-xmlrpc 2007-11-07 12:56:19 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0621.html
Comment 15 H.J. Lu 2007-11-08 13:58:31 EST
Which autofs fixes this? I have autofs-5.0.1-0.rc2.55 and autofs doesn't work
for me.
Comment 16 Jeffrey Moyer 2007-11-08 14:13:40 EST
(In reply to comment #15)
> Which autofs fixes this? I have autofs-5.0.1-0.rc2.55 and autofs doesn't work
> for me.

You're likely running into a kernel bug.  It will be fixed in the z-stream and 5.2.

Just for clarification, does the first attempt to access an automounted share
fail, then a second succeed?
Comment 17 H.J. Lu 2007-11-08 14:18:24 EST
(In reply to comment #16)
> 
> Just for clarification, does the first attempt to access an automounted share
> fail, then a second succeed?

Yes, that is exactly my problem and is a regression from RHEL 5.0.
Comment 18 Jeffrey Moyer 2008-02-28 12:52:24 EST
*** Bug 431918 has been marked as a duplicate of this bug. ***
Comment 19 Thorsten Scherf 2008-03-12 12:01:10 EDT
which kernel version could be used to avoid this bug in 5.1?
Comment 20 Ian Kent 2008-03-13 03:17:38 EDT
(In reply to comment #19)
> which kernel version could be used to avoid this bug in 5.1?
> 

If you're asking about the "first mount attempt incorrectly
returns a fail to user space" then the missing patches were
included in 2.6.18-53.1.4.

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