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 ----
This is a regression against autofs v4
Missing line from /etc/auto.master (example #1) /data file:/etc/auto_data Typo in Example#2: auto_master ->> auto.master
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
(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.
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
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)
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.
(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
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.
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.
So, in reality, this isn't strictly a regression it's an update for an incomplete fix previously applied.
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
(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
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
(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
Trying that again - I see I'm still trying .1. need to use .2.
(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)
(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.
(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
Created attachment 372421 [details] Patch - check for path mount location in generic module
Created attachment 372422 [details] Patch - dont fail mount on access fail
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
- 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.
(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
(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
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.
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
(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.
(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
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