Bug 537403 - Autofs mount fails if it relies on another autofs managed resource
Summary: Autofs mount fails if it relies on another autofs managed resource
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: autofs
Version: 5.3
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Ian Kent
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1070587
TreeView+ depends on / blocked
 
Reported: 2009-11-13 14:32 UTC by v-burns
Modified: 2018-10-27 15:36 UTC (History)
4 users (show)

Fixed In Version: autofs-5.0.1-0.rc2.133.el5
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1070587 (view as bug list)
Environment:
Last Closed: 2010-03-30 08:37:21 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Patch to fix fix recursive loopback mounts (852 bytes, patch)
2009-11-19 03:55 UTC, Ian Kent
no flags Details | Diff
Patch - dont fail mount on access fail (1.23 KB, patch)
2009-11-19 04:38 UTC, Ian Kent
no flags Details | Diff
Patch - backport fix for "fix fix recursive loopback mounts" (849 bytes, patch)
2009-11-19 14:53 UTC, Ian Kent
no flags Details | Diff
Patch - check for path mount location in generic module (1.96 KB, patch)
2009-11-20 06:13 UTC, Ian Kent
no flags Details | Diff
Patch - dont fail mount on access fail (1.22 KB, patch)
2009-11-20 06:14 UTC, Ian Kent
no flags Details | Diff
Patch - check for path mount location in generic module (2.74 KB, patch)
2009-11-20 13:25 UTC, Ian Kent
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0265 0 normal SHIPPED_LIVE autofs bug fix update 2010-03-29 12:54:19 UTC

Description v-burns 2009-11-13 14:32:23 UTC
Description of problem:

Automount managed resources fail if they rely on secondary managed mounts that are not mounted. Examples of this behavior are most commonly observed when an ISO or other FS-type are located on an NFS resource. When both are autofs managed the mount attempt of the ISO or other FS-type fail when the requisite NFS managed mount is not already mounted.

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

Believed to be an issue with all releases of autofs5
RHEL5u3: 2.6.18-128.el5xen
autofs-5.0.1-0.rc2.102

How reproducible:

------------------------------------------------------------------------
Example #1: using ISO located on NFS share
------------------------------------------------------------------------

/etc/auto.master
/readonly file:/etc/auto_ro

/etc/auto_ro
myiso   -fstype=iso9660,loop=/dev/loop0,ro :/data/ftp-rhel5/rhel-server-5.3-i386-dvd.iso

/etc/auto_data
ftp-rhel5 myfiler:/vol/fvol22/stuff


$ cd /data/myiso    (fails) the ISO is unavailable (not found)
ksh: cd: /vobs/myiso: [No such file or directory]
$ ls -al /data/ftp-rhel5/rhel-server-5.3-i386-dvd.iso
-rw-rw-r-- 1 blah blah 3013859328 Feb 17  2009 /data/ftp-rhel5/rhel-server-5.3-i386-dvd.iso
$ cd /data/myiso
$ ls -l
total 22897
dr-xr-xr-x 3 root root   8192 Jan  6  2009 Cluster
dr-xr-xr-x 3 root root   8192 Jan  6  2009 ClusterStorage
-r--r--r-- 7 root root   8445 Sep  2  2008 EULA
-r--r--r-- 7 root root  18416 Nov 30  2006 GPL
  --- SNIP ---
dr-xr-xr-x 3 root root 397312 Jan  6  2009 Server
-r--r--r-- 1 root root  30911 Jan  6  2009 TRANS.TBL
dr-xr-xr-x 3 root root   8192 Jan  6  2009 VT
-r--r--r-- 3 root root   8445 Dec 15  2008 eula.en_US
dr-xr-xr-x 4 root root   2048 Jan  6  2009 images
dr-xr-xr-x 2 root root   2048 Jan  6  2009 isolinux
$ 

------------------------------------------------------------------------
EXAMPLE #2: Using MVFS resource on NFS share
------------------------------------------------------------------------

I'm attempting to use autofs and the MVFS file-system together. In a UNIX environment the MVFS file systems are stored on filers and shared via NFS. Clearcase uses an NFS mounted resource and then mounts it again locally using mvfs (breathing life into it).
 
Data:
/etc/auto_master
/vobs        file:/etc/auto_vobs
/clearcase   file:/etc/auto_clearcase

/etc/auto_clearcase
vobs filerA:/vol/fvol200/vobs

/etc/auto_vobs
myvob    -fstype=mvfs   :/clearcase/vobs/ccaseadm/WSS/myvob.vbs

----

Comment 1 v-burns 2009-11-13 14:35:19 UTC
This is a regression against autofs v4

Comment 2 v-burns 2009-11-13 14:48:55 UTC
Missing line from /etc/auto.master (example #1)
/data file:/etc/auto_data

Typo in Example#2: auto_master ->> auto.master

Comment 3 v-burns 2009-11-16 13:32:09 UTC
It is interesting to note that the ISO example works as expected under the following test environment. The other/second example has not been tested in this environment yet, although it is expected to work because this example works.

ENVIRONMENT:
$ cat /etc/SuSE-release
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 0
$ rpm -q autofs
autofs-5.0.3-89.11

Comment 4 Ian Kent 2009-11-16 14:17:27 UTC
(In reply to comment #3)
> It is interesting to note that the ISO example works as expected under the
> following test environment. The other/second example has not been tested in
> this environment yet, although it is expected to work because this example
> works.
> 
> ENVIRONMENT:
> $ cat /etc/SuSE-release
> SUSE Linux Enterprise Server 11 (x86_64)
> VERSION = 11
> PATCHLEVEL = 0
> $ rpm -q autofs
> autofs-5.0.3-89.11  

I'd be interested to see the debug log output from that
please.

Comment 5 v-burns 2009-11-16 15:39:09 UTC
On suse-11 I configured the setup below (for completeness) as it is a little different than described before but not expected to make a difference. (map names and locations as well as using NIS)

/etc/auto.master
+auto.master

NIS:auto.master
/vobs  file:/etc/automap/auto_vobs
/data  auto_data
--snip--

NIS:auto_data
ftp-rhel5 some-filer:/vol/fvol14/rhel5
--snip--

/etc/automap/auto_vobs
myiso  -fstype=iso9660,loop,ro :/data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso
--snip--

Nothing except home dir is mounted (even rebooted system to make it fresh)

$ mount|egrep 'vobs|rhel5|mysql'
$ cd /data/myiso
$ ls -l
total 22897
dr-xr-xr-x 3 root root   8192 Jan  6  2009 Cluster
dr-xr-xr-x 3 root root   8192 Jan  6  2009 ClusterStorage
-r--r--r-- 7 root root   8445 Sep  2  2008 EULA
-r--r--r-- 7 root root  18416 Nov 30  2006 GPL
  --- SNIP ---
dr-xr-xr-x 3 root root 397312 Jan  6  2009 Server
-r--r--r-- 1 root root  30911 Jan  6  2009 TRANS.TBL
dr-xr-xr-x 3 root root   8192 Jan  6  2009 VT
-r--r--r-- 3 root root   8445 Dec 15  2008 eula.en_US
dr-xr-xr-x 4 root root   2048 Jan  6  2009 images
dr-xr-xr-x 2 root root   2048 Jan  6  2009 isolinux
$ mount|egrep 'vobs|rhel5|mysql'
some-filer:/vol/fvol14/rhel5 on /data/ftp-rhel5 type nfs (rw,nosuid,intr,timeo=600,retrans=2,retry=100,rsize=32768,wsize=32768,sloppy,addr=128.247.49.18,nfsvers=3,proto=tcp,mountproto=udp)
/dev/loop2 on /vobs/myiso type iso9660 (ro)
$ 

The only messages logged were...
Nov 16 09:14:53 testhost kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
Nov 16 09:14:53 testhost kernel: ISO 9660 Extensions: RRIP_1991A

I then reconfigured the autofs for debugging messages. After clearing all mounts, restarting and performing the test once more I got these logs. The first mount attempt triggers the second to make the first successful.

Nov 16 09:25:48 dflvs1000 automount[3506]: handle_packet: type = 3
Nov 16 09:25:48 dflvs1000 automount[3506]: handle_packet_missing_indirect: token 70, name myiso, request pid 4109
Nov 16 09:25:48 dflvs1000 automount[3506]: attempting to mount entry /vobs/myiso
Nov 16 09:25:48 dflvs1000 automount[3506]: lookup_mount: lookup(file): looking up myiso
Nov 16 09:25:48 dflvs1000 automount[3506]: lookup_mount: lookup(file): myiso -> -fstype=iso9660,loop,ro :/data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso
Nov 16 09:25:48 dflvs1000 automount[3506]: parse_mount: parse(sun): expanded entry: -fstype=iso9660,loop,ro :/data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso
Nov 16 09:25:48 dflvs1000 automount[3506]: parse_mount: parse(sun): gathered options: fstype=iso9660,loop,ro
Nov 16 09:25:48 dflvs1000 automount[3506]: parse_mount: parse(sun): dequote(":/data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso") -> :/data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso
Nov 16 09:25:48 dflvs1000 automount[3506]: parse_mount: parse(sun): core of entry: options=fstype=iso9660,loop,ro, loc=:/data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso
Nov 16 09:25:48 dflvs1000 automount[3506]: sun_mount: parse(sun): mounting root /vobs, mountpoint myiso, what /data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso, fstype iso9660, options loop,ro
Nov 16 09:25:48 dflvs1000 automount[3506]: do_mount: /data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso /vobs/myiso type iso9660 options loop,ro using module generic
Nov 16 09:25:48 dflvs1000 automount[3506]: mount_mount: mount(generic): calling mkdir_path /vobs/myisoNov 16 09:25:48 dflvs1000 automount[3506]: mount_mount: mount(generic): calling mount -t iso9660 -s -o loop,ro /data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso /vobs/myiso
Nov 16 09:25:48 dflvs1000 automount[3506]: handle_packet: type = 3
Nov 16 09:25:49 dflvs1000 automount[3506]: handle_packet_missing_indirect: token 71, name ftp-rhel5, request pid 4111
Nov 16 09:25:49 dflvs1000 automount[3506]: attempting to mount entry /data/ftp-rhel5
Nov 16 09:25:49 dflvs1000 automount[3506]: file map not found
Nov 16 09:25:49 dflvs1000 automount[3506]: lookup_mount: lookup(yp): looking up ftp-rhel5
Nov 16 09:25:49 dflvs1000 automount[3506]: lookup_mount: lookup(yp): ftp-rhel5 -> some-filer:/vol/fvol14/rhel5
Nov 16 09:25:49 dflvs1000 automount[3506]: parse_mount: parse(sun): expanded entry: some-filer:/vol/fvol14/rhel5
Nov 16 09:25:49 dflvs1000 automount[3506]: parse_mount: parse(sun): gathered options: rw,intr,timeo=600,retrans=2,vers=3,proto=tcp,nosuid,retry=100,rsize=32768,wsize=32768
Nov 16 09:25:49 dflvs1000 automount[3506]: parse_mount: parse(sun): dequote("some-filer:/vol/fvol14/rhel5") -> some-filer:/vol/fvol14/rhel5
Nov 16 09:25:49 dflvs1000 automount[3506]: parse_mount: parse(sun): core of entry: options=rw,intr,timeo=600,retrans=2,vers=3,proto=tcp,nosuid,retry=100,rsize=32768,wsize=32768, loc=some-filer:/vol/fvol14/rhel5
Nov 16 09:25:49 dflvs1000 automount[3506]: sun_mount: parse(sun): mounting root /data, mountpoint ftp-rhel5, what some-filer:/vol/fvol14/rhel5, fstype nfs, options rw,intr,timeo=600,retrans=2,vers=3,proto=tcp,nosuid,retry=100,rsize=32768,wsize=32768
Nov 16 09:25:52 dflvs1000 automount[3506]: mount_mount: mount(nfs): root=/data name=ftp-rhel5 what=some-filer:/vol/fvol14/rhel5, fstype=nfs, options=rw,intr,timeo=600,retrans=2,vers=3,proto=tcp,nosuid,retry=100,rsize=32768,wsize=32768
Nov 16 09:25:52 dflvs1000 automount[3506]: mount_mount: mount(nfs): nfs options="rw,intr,timeo=600,retrans=2,vers=3,proto=tcp,nosuid,retry=100,rsize=32768,wsize=32768", nosymlink=0, ro=0
Nov 16 09:25:52 dflvs1000 automount[3506]: mount_mount: mount(nfs): calling mkdir_path /data/ftp-rhel5Nov 16 09:25:52 dflvs1000 automount[3506]: mount_mount: mount(nfs): calling mount -t nfs -s -o rw,intr,timeo=600,retrans=2,vers=3,proto=tcp,nosuid,retry=100,rsize=32768,wsize=32768 some-filer:/vol/fvol14/rhel5 /data/ftp-rhel5
Nov 16 09:25:52 dflvs1000 automount[3506]: mount(nfs): mounted some-filer:/vol/fvol14/rhel5 on /data/ftp-rhel5
Nov 16 09:25:52 dflvs1000 automount[3506]: send_ready: token = 71
Nov 16 09:25:52 dflvs1000 automount[3506]: mounted /data/ftp-rhel5
Nov 16 09:25:52 dflvs1000 kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
Nov 16 09:25:52 dflvs1000 kernel: ISO 9660 Extensions: RRIP_1991A
Nov 16 09:25:52 dflvs1000 automount[3506]: mount(generic): mounted /data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso type iso9660 on /vobs/myiso
Nov 16 09:25:55 dflvs1000 automount[3506]: send_ready: token = 70
Nov 16 09:25:55 dflvs1000 automount[3506]: mounted /vobs/myiso

Comment 8 v-burns 2009-11-18 17:30:12 UTC
Testing of autofs-5.0.1-0.rc2.131.el5_4.1 on RHEL5.3 fails the test. It was recommended that we try based on it having many 5.0.3 patches back ported (so it was suggested by Novell)

Comment 11 Ian Kent 2009-11-19 02:42:39 UTC
There is something fishy going on here!

Now I actually look at the code it turns out that just
about everything I've been saying so far is just plain
wrong. Maybe I should "never" rely on my memory, DOH!

In fact, this should work fine AFAICS as the original change
to support this was for exactly this case, not for the mount
point path at all. So this is really a regression against our
current version or maybe just a missing patch. Let me look
further.

We never did get a debug log for the failure case, only
for the 5.0.3 success case. Can you provide one please.

Comment 12 Ian Kent 2009-11-19 02:53:38 UTC
(In reply to comment #11)
> There is something fishy going on here!

There certainly is!

snip ...

> In fact, this should work fine AFAICS as the original change
> to support this was for exactly this case, not for the mount
> point path at all. So this is really a regression against our
> current version or maybe just a missing patch. Let me look
> further.

There is a patch missing which went into 5.0.3.
There are so many patches, sorry I missed this one.

I'll get a test package together but I think it might be wise
to also fix the other issue I mentioned. That should be quite
straight forward anyway.

Ian

Comment 13 Ian Kent 2009-11-19 03:55:51 UTC
Created attachment 370260 [details]
Patch to fix fix recursive loopback mounts

This is the missing patch back ported to apply to our
current RHEL source.

Comment 14 Ian Kent 2009-11-19 04:38:31 UTC
Created attachment 370270 [details]
Patch - dont fail mount on access fail

This is a patch the other issue that's needed attention for a
while now.

Comment 15 Ian Kent 2009-11-19 04:40:41 UTC
So, in reality, this isn't strictly a regression it's an update
for an incomplete fix previously applied.

Comment 16 Ian Kent 2009-11-19 07:16:24 UTC
A build with the above two patches included can be found at:
http://people.redhat.com/~ikent/autofs-5.0.1-0.rc2.132.bz537403.1

Please test this out.
Ian

Comment 17 v-burns 2009-11-19 13:17:18 UTC
(In reply to comment #11)

My bad, I thought the log had both a fail and working example. I guess I missed the bad part.

Nov 19 07:13:11 dflvs0006 automount[10172]: handle_packet: type = 3
Nov 19 07:13:11 dflvs0006 automount[10172]: handle_packet_missing_indirect: token 3653, name myiso, request pid 10271
Nov 19 07:13:11 dflvs0006 automount[10172]: attempting to mount entry /vobs/myiso
Nov 19 07:13:11 dflvs0006 automount[10172]: lookup_mount: lookup(file): looking up myiso
Nov 19 07:13:11 dflvs0006 automount[10172]: lookup_mount: lookup(file): myiso -> -fstype=iso9660,loop,ro :/data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso
Nov 19 07:13:11 dflvs0006 automount[10172]: parse_mount: parse(sun): expanded entry: -fstype=iso9660,loop,ro :/data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso
Nov 19 07:13:11 dflvs0006 automount[10172]: parse_mount: parse(sun): gathered options: fstype=iso9660,loop,ro
Nov 19 07:13:11 dflvs0006 automount[10172]: parse_mount: parse(sun): dequote(":/data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso") -> :/data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso
Nov 19 07:13:11 dflvs0006 automount[10172]: parse_mount: parse(sun): core of entry: options=fstype=iso9660,loop,ro, loc=:/data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso
Nov 19 07:13:11 dflvs0006 automount[10172]: sun_mount: parse(sun): mounting root /vobs, mountpoint myiso, what /data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso, fstype iso9660, options loop,ro
Nov 19 07:13:11 dflvs0006 automount[10172]: do_mount: /data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso /vobs/myiso type iso9660 options loop,ro using module generic
Nov 19 07:13:11 dflvs0006 automount[10172]: mount_mount: mount(generic): calling mkdir_path /vobs/myiso
Nov 19 07:13:11 dflvs0006 automount[10172]: mount_mount: mount(generic): calling mount -t iso9660 -s -o loop,ro /data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso /vobs/myiso
Nov 19 07:13:11 dflvs0006 automount[10172]: >> /data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso: No such file or directory
Nov 19 07:13:11 dflvs0006 automount[10172]: mount(generic): failed to mount /data/ftp-rhel5/x86_64/server/5.3/rhel-server-5.3-x86_64-dvd.iso (type iso9660) on /vobs/myiso
Nov 19 07:13:11 dflvs0006 automount[10172]: ioctl_send_fail: token = 3653
Nov 19 07:13:11 dflvs0006 automount[10172]: failed to mount /vobs/myiso

Comment 18 Ian Kent 2009-11-19 14:53:40 UTC
Created attachment 370359 [details]
Patch - backport fix for "fix fix recursive loopback mounts"

Fix back port error in loop traversal pointer, oops!

This works fine in 5.0.3 and later and it looks like I've
got it right now.

Please try again with:
http://people.redhat.com/~ikent/autofs-5.0.1-0.rc2.132.bz537403.2

Comment 19 v-burns 2009-11-19 19:51:40 UTC
(In reply to comment #18)

# rpm -Uvh /tmp/autofs-5.0.1-0.rc2.132.bz537403.1.el5.x86_64.rpm
Preparing...                ########################################### [100%]
   1:autofs                 ########################################### [100%]
#

Nov 19 13:47:05 dflvs0006 automount[32758]: Starting automounter version 5.0.1-0.rc2.132.bz537403.1.el5, master map auto.master
Nov 19 13:47:05 dflvs0006 automount[32758]: using kernel protocol version 5.00
Nov 19 13:47:05 dflvs0006 automount[32758]: lookup_nss_read_master: reading master files auto.master
Nov 19 13:47:05 dflvs0006 automount[32758]: parse_init: parse(sun): init gathered global options: (null)
Nov 19 13:47:05 dflvs0006 kernel: automount[32758]: segfault at 0000000000000000 rip 00002b94377c3105 rsp 00007fff732f3a20 error 4

Comment 20 v-burns 2009-11-19 20:07:13 UTC
Trying that again - I see I'm still trying .1. need to use .2.

Comment 21 v-burns 2009-11-19 20:49:01 UTC
(In reply to comment #18)
> http://people.redhat.com/~ikent/autofs-5.0.1-0.rc2.132.bz537403.2  

Now that I have my glasses on and loaded the correct package (long strings of numbers did me in).

I have been trying it for several minutes and it has been working repeatedly sith the ISO9660 but not with the MVFS.

- The ISO example works.
- The MVFS example - so far not working (relooking at it on my end)

Comment 22 Ian Kent 2009-11-20 00:58:19 UTC
(In reply to comment #21)
> (In reply to comment #18)
> > http://people.redhat.com/~ikent/autofs-5.0.1-0.rc2.132.bz537403.2  
> 
> Now that I have my glasses on and loaded the correct package (long strings of
> numbers did me in).
> 
> I have been trying it for several minutes and it has been working repeatedly
> sith the ISO9660 but not with the MVFS.
> 
> - The ISO example works.
> - The MVFS example - so far not working (relooking at it on my end)  

Please post a debug log.

Comment 23 Ian Kent 2009-11-20 01:25:01 UTC
(In reply to comment #0)
> ------------------------------------------------------------------------
> EXAMPLE #2: Using MVFS resource on NFS share
> ------------------------------------------------------------------------
> 
> I'm attempting to use autofs and the MVFS file-system together. In a UNIX
> environment the MVFS file systems are stored on filers and shared via NFS.
> Clearcase uses an NFS mounted resource and then mounts it again locally using
> mvfs (breathing life into it).
> 
> Data:
> /etc/auto_master
> /vobs        file:/etc/auto_vobs
> /clearcase   file:/etc/auto_clearcase
> 
> /etc/auto_clearcase
> vobs filerA:/vol/fvol200/vobs
> 
> /etc/auto_vobs
> myvob    -fstype=mvfs   :/clearcase/vobs/ccaseadm/WSS/myvob.vbs
> 
> ----  

So this doesn't work ... we've made some progress.

Are you sure this works with the SuSE package. I think it probably
shouldn't, given the code in the generic mount module looks
specifically for the "loop" option when deciding if it needs to
set the flag to trigger mounts in the dependent path. The only
other place dependent path mounts are triggered is in the bind
mount module, but in this case the mvfs mount will use the
generic mount module (I think, debug will verify this) and so
will not set the flag.

If you can verify that it also doesn't work with the SuSE package
then we know this is missing functionality and I can add a special
case in the generic mount module to catch it.

Ian

Comment 24 Ian Kent 2009-11-20 06:13:28 UTC
Created attachment 372421 [details]
Patch - check for path mount location in generic module

Comment 25 Ian Kent 2009-11-20 06:14:27 UTC
Created attachment 372422 [details]
Patch - dont fail mount on access fail

Comment 26 Ian Kent 2009-11-20 07:16:36 UTC
I've gone ahead with this, assuming that I understand the problem
and the mvfs mount doesn't work in the 5.0.3 version.

Please try again with:
http://people.redhat.com/~ikent/autofs-5.0.1-0.rc2.132.bz537403.3

Comment 27 v-burns 2009-11-20 12:34:32 UTC
- The latest patch provided now works for both examples (ISO, MVFS) on RHEL5u3. Should I consider this package the release I should use or will there be a more official release number later?

- The ISO example works on Suse-11 (not sure why, but it does). The MVFS example is untested on Suse because we do not have Clearcase infrastructure or resources for Suse.

- Both examples failed on RHEL5u3 – both examples should have had the same automount code path because both rely on the “generic” mount mechanism. Therefore it was at least somewhat reasonable that if one failed the other would and if one worked so would the other (our hope). The ISO example was provided as a simplified means of reproducing the behavior without needing Clearcase and the MVFS filesystem.

The good news is that we now have something that works. I’m on vacation so I’ll hand it off to one of my team members so they can deploy it on a production server and have a few users hammer on it.

Comment 28 Ian Kent 2009-11-20 13:14:32 UTC
(In reply to comment #27)
> - The latest patch provided now works for both examples (ISO, MVFS) on RHEL5u3.
> Should I consider this package the release I should use or will there be a more
> official release number later?

I'll leave this to others to answer.

The package you have is essentially the RHEL-5.4 package with some
bug fixes scheduled for 5.5 plus the dependent mount fixes.

> 
> - The ISO example works on Suse-11 (not sure why, but it does). The MVFS
> example is untested on Suse because we do not have Clearcase infrastructure or
> resources for Suse.

It works because 5.0.3 had a patch specifically for the ISO case
which was never included in our RHEL release. I believe the MVFS
case would not work on the SuSE version and the change included
in revision 3 of the package here addresses that omission of the
original 5.0.3 change. This correction will also be included in
the current upstream (5.0.5) patch series.

> 
> - Both examples failed on RHEL5u3 – both examples should have had the same
> automount code path because both rely on the “generic” mount mechanism.
> Therefore it was at least somewhat reasonable that if one failed the other
> would and if one worked so would the other (our hope). The ISO example was
> provided as a simplified means of reproducing the behavior without needing
> Clearcase and the MVFS filesystem.

We know now what is going on.

The original 5.0.3 change explicitly checked for mount option
"loop" in the generic mount module and if found set a flag that
caused the dependent path to be resolved prior to exec'ing the
mount command. When that option isn't present the flag isn't set
so the dependent path isn't resolved prior to the mount exec.

The other case where the flag is always set is bind mounts and
the MVFS example clearly isn't a bind mount, ;)

I thought my explanations in the patches I've posted here were
fairly clear on this but maybe not?

> 
> The good news is that we now have something that works. I’m on vacation so I’ll
> hand it off to one of my team members so they can deploy it on a production
> server and have a few users hammer on it.  

Thanks.
Ian

Comment 29 Ian Kent 2009-11-20 13:19:19 UTC
(In reply to comment #28)
> We know now what is going on.
> 
> The original 5.0.3 change explicitly checked for mount option
> "loop" in the generic mount module and if found set a flag that
> caused the dependent path to be resolved prior to exec'ing the
> mount command. When that option isn't present the flag isn't set
> so the dependent path isn't resolved prior to the mount exec.

For the benefit of anyone that may look a bit closer at the
patch, the above is not entirely accurate but is close enough
for the purpose of our explanation.

Ian

Comment 30 Ian Kent 2009-11-20 13:25:29 UTC
Created attachment 372487 [details]
Patch - check for path mount location in generic module

The patch that was originally uploaded is not the patch
that has been used to resolve this. Not sure how that
mistake was made but this is the correct one. Note the
order in the rpm is this patch first and then the "dont
fail mount on access fail" patch.

Comment 31 Ian Kent 2009-11-20 13:35:14 UTC
I guess the other question is, what other file systems do
we have that aren't mounted using the loopback device that
use a local path as the mount location?

We'll need that for our RHTS test.

Ian

Comment 32 v-burns 2009-11-20 13:54:48 UTC
(In reply to comment #31)
> I guess the other question is, what other file systems do
> we have that aren't mounted using the loopback device that
> use a local path as the mount location?
> We'll need that for our RHTS test.
> Ian  

ISO's are very common, MVFS is the only other special case of this behavior I know of. I'm sure there are others but they are not something I use so they are off my radar screen.

Here’s a thought: how hard would it be to add an option to /etc/sysconfig/autofs that allowed the system admin to construct a list of additional flags and/or fstypes that would allow for dynamic control of this feature/support? Fore example it could allow the setting of “mvfs” filesystem type to trigger this feature. This would allow administrators to place other types on the list at their discretion, just a thought. In a pinch an option could be used to make all "generic" mount requests run in a different process group.

Comment 33 Ian Kent 2009-11-20 14:34:34 UTC
(In reply to comment #32)
> (In reply to comment #31)
> > I guess the other question is, what other file systems do
> > we have that aren't mounted using the loopback device that
> > use a local path as the mount location?
> > We'll need that for our RHTS test.
> > Ian  
> 
> ISO's are very common, MVFS is the only other special case of this behavior I
> know of. I'm sure there are others but they are not something I use so they are
> off my radar screen.

Me too.

> 
> Here’s a thought: how hard would it be to add an option to
> /etc/sysconfig/autofs that allowed the system admin to construct a list of
> additional flags and/or fstypes that would allow for dynamic control of this
> feature/support? Fore example it could allow the setting of “mvfs” filesystem
> type to trigger this feature. This would allow administrators to place other
> types on the list at their discretion, just a thought. In a pinch an option
> could be used to make all "generic" mount requests run in a different process
> group.  

I don't think it's needed.

With this change any file system, other than cifs, that has a mount
location that starts with "/" will cause an attempt to resolve the
dependent path. Note also that the second patch removes the check of
the return from the system call that triggers the resolution so even
if that fails the mount still has a chance to succeed. Even if we
didn't check for cifs, trying to resolve that mount location would
fail but the mount itself should still succeed (assuming it should)
and the same for other cases of course.

Ian

Comment 39 errata-xmlrpc 2010-03-30 08:37:21 UTC
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 therefore 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-2010-0265.html


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