Bug 137998 - autofs removes leading path components of /net mounts on timeout
Summary: autofs removes leading path components of /net mounts on timeout
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Moyer
QA Contact:
Depends On:
Blocks: 168424
TreeView+ depends on / blocked
Reported: 2004-11-03 18:03 UTC by David Lehman
Modified: 2007-11-30 22:07 UTC (History)
5 users (show)

Fixed In Version: RHSA-2006-0144
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-15 15:45:44 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Don't expire /net mounts when scaffolding directories have references (2.46 KB, patch)
2005-05-25 21:01 UTC, Jeff Moyer
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2006:0144 qe-ready SHIPPED_LIVE Moderate: Updated kernel packages available for Red Hat Enterprise Linux 3 Update 7 2006-03-15 05:00:00 UTC

Description David Lehman 2004-11-03 18:03:48 UTC
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):

How reproducible:

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.

Comment 2 Jeff Moyer 2004-11-15 20:02:33 UTC
Does Solaris also keep the filesystem mounted in this case?

Comment 3 David Lehman 2004-11-15 20:21:18 UTC
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.

Comment 4 David Lehman 2004-11-15 20:33:39 UTC
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.

Comment 5 Kiersten (Kerri) Anderson 2004-11-24 16:09:00 UTC
Any update on this one?  Is it something Chris can take a look at?

Comment 6 Chris Feist 2004-12-08 22:21:16 UTC
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.

Comment 15 Kiersten (Kerri) Anderson 2005-03-08 20:27:54 UTC
Putting on blocker list for U6.

Comment 17 Jeff Moyer 2005-05-25 21:01:43 UTC
Created attachment 114855 [details]
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 22 Ernie Petrides 2005-09-21 21:07:16 UTC
Changing component to "kernel".

Comment 23 Jeff Moyer 2005-09-28 13:44:36 UTC
A patch to fix this problem has been proposed for internal review.

Comment 24 Ernie Petrides 2005-09-30 06:43:18 UTC
A fix for this problem has just been committed to the RHEL3 U7
patch pool this evening (in kernel version 2.4.21-37.4.EL).

Comment 27 Red Hat Bugzilla 2006-03-15 15:45:44 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.


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