On Mon, 2006-10-30 at 09:53 +0000, [EMAIL PROTECTED] wrote: > > I'm likely to end up saying that manual umounting of automounted > > shares is a bad thing and doing so may lead to unpredictable > > behavior. I may be able to improve matters but it is unlikely to be > > totally reliable. > > So I recommend leaving the automounts alone. > > In an ideal world, yes of course, but in reality in large production > environments with NFS servers going down and/or hanging from time to > time for various reasons I think it's a situation that needs to be > accounted for.
In any world really. The man pages for the Solaris automounter say much the same thing. Never the less, it looks like there is some more work to be done in this area. Also, not all types of automounts will not work properly when they are manually umounted but I can't say it's OK for some and not others as that will introduce confusion. In particular, manually umounting parts of nested mount trees is not something that should be attempted at all. > > Failing that, an alternative procedure? Stop the automounter, unmount, > and restart it perhaps? As it turns out the FC6 build uses the "--enable-ignore-busy" configure option. If mounts are wedged then restarting autofs will unlink umount all mounts and start afresh. This allows existing processes using mounts that aren't wedged to continue until they are done with the mount, while new mount requests are handled by the new daemon. Clearly, if a mount is blocked in an uninterruptable sleep then they won't be released by the kernel and the process that is stuck would need to be encouraged to go away in a fairly forceful manner, if it can be persuaded to go away at all. This is not a perfect solution because there is a finite amount of time that there is no daemon to answer requests but I can't see any other way to deal with this. I've given this problem a lot of thought and considerable effort and it's about as good as it can be until I can come up with something better if that's possible. Ian _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
