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.
Does Solaris also keep the filesystem mounted in this case?
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.
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.
Any update on this one? Is it something Chris can take a look at?
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.
Putting on blocker list for U6.
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.
Changing component to "kernel".
A patch to fix this problem has been proposed for internal review.
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).
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-0144.html