Bug 168431

Summary: autofs removes leading path components of /net mounts on timeout
Product: Red Hat Enterprise Linux 4 Reporter: Jeff Moyer <jmoyer>
Component: kernelAssignee: Jeff Moyer <jmoyer>
Status: CLOSED ERRATA QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.0CC: cfeist, k.georgiou, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: RHSA-2006-0132 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-03-07 19:58:00 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 168429    
Attachments:
Description Flags
don't expire mount when scaffolding dirs have references
none
don't expire in-use directory hierarchies in multi-mount maps none

Description Jeff Moyer 2005-09-15 21:25:49 UTC 
+++ This bug was initially created as a clone of Bug #137998 +++

Description of problem:
Leading path components of /net mounts are removed when unmounting, even if
there are procs whose CWD is in there.

Version-Release number of selected component (if applicable):
autofs-4.1.3-12
kernel-2.4.21-20.EL

How reproducible:
Always

Steps to Reproduce:
1. set up a non-/ NFS export somewhere (eg: gonzo:/mnt/foo)
2. cd into a leading component of the /net mountpoint (eg: cd /net/gonzo/mnt)
3. wait for 5 minutes (or whatever your timeout is set to) and try 'ls'
  
Actual results:
[root@hogwash mnt]# ls
ls: .: No such file or directory

Expected results:
[root@hogwash mnt]# ls
foo  bar

Additional info:
I tried this with Solaris (SunOS 5.7) and it seems to preserve leading
components at least while they are opened by a process.

-- Additional comment from jmoyer on 2004-11-15 15:02 EST --
Does Solaris also keep the filesystem mounted in this case?

-- Additional comment from dlehman on 2004-11-15 15:21 EST --
No. I see the unmount request in the server's logs. It looks like Solaris keeps
the leading directory components of the exported paths around whether or not
anyone's in the path, but I'm not sure for how long.


-- Additional comment from dlehman on 2004-11-15 15:33 EST --
I messed around some more - here's what I saw:

I exported gonzo:/mnt/iso, then listed /net/gonzo/mnt/iso. I waited until I saw
the unmount request after the timeout (I set it to 60 sec), then listed /net and
still saw 'gonzo'. I listed /net/gonzo without seeing an exports request in
gonzo's log and saw 'mnt'. When I list /net/gonzo/mnt I see an exports request
in gonzo's log and I see 'iso' as the output of ls. I list /net again six
minutes later and it's empty. So it looks like there's a seperate timeout for
removing a /net mount's parent dir.

-- Additional comment from cfeist on 2004-12-08 17:21 EST --
I was able to replicate the bug on my system and it appears to require
a kernel patch to fix.  I'm currently investigating what will be
required to prevent the unmount from happening.

-- Additional comment from jmoyer on 2005-05-25 17:01 EST --
Created an attachment (id=114855)
Don't expire /net mounts when scaffolding directories have references

This is a backported patch of the upstream fix for this problem.  I have tested
it, and it resolves the issue in my environment.
Comment 1 Jeff Moyer 2005-09-15 21:25:50 UTC 
Created attachment 118870 [details]
don't expire mount when scaffolding dirs have references
Comment 2 Jeff Moyer 2005-09-28 13:44:19 UTC 
A patch to fix this problem has been proposed for internal review.
Comment 3 Jeff Moyer 2005-09-28 13:45:17 UTC 
changing component to kernel.
Comment 11 Jeff Moyer 2005-10-27 20:24:16 UTC 
No, the patch isn't dependent upon another patch.  This patch seems to be for
the wrong kernel.  2.4 (and earlier 2.6) had this function.

I'll work it out.
Comment 12 Jeff Moyer 2005-10-27 23:09:15 UTC 
Created attachment 120491 [details]
don't expire in-use directory hierarchies in multi-mount maps
Comment 26 Red Hat Bugzilla 2006-03-07 19:58:00 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 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/RHSA-2006-0132.html