On Fri, 23 Jan 2004, Mike Marion wrote: > > The program works exactly like expected, and has been working for quite > some time. This is either a problem that didn't exist before, or we > just somenow never triggered it before.
Cool. > > I found out that if you just cd into the path and sit there, it'll trip > the bug, no need to have one of the NFS mounts below it triggered at > all. I had a feeling I'd had this type of trouble before and sure enough I have. Worse I never fixed it. The problem has always been there and perhaps you have not triggered it before. It happens because the daemon thinks that if all mounts under the mount point are not busy it can umount the submount (there must be an -fstype=autofs there somewhere yes, probably /usr/local/projects/some/automount/submount itself I hope) itself. Or you are trying to shutdown the top mount when it is busy in the same way. I think you'll get the same result. The daemon can't identify that the mount point itself is busy as it uses the entries in mtab to work out if there is more to expire. So onward and downward it goes. But it can't complete the umount of course because, it itself is busy. Anything like a program with an open file handle on the directory or a process with it as pwd will cause this. The gotya is that if it gets to the umount stage it's already to late to save it. Ahh, he says, I put an ioctl in the kernel module ages ago, for this very reason, but never implemented its intended use. Bottom line is that I can fix this for 4.1.1 (out soonish) combined with my kernel module only. So, sorry to those that can't or have chosen not to upgrade there module. I can't think of a more general way to fix it. Are up for testing the fix Mike? Ian _______________________________________________ autofs mailing list [EMAIL PROTECTED] http://linux.kernel.org/mailman/listinfo/autofs
