On Thursday 03 May 2012 10:29:07 Phillip Susi wrote: > On 5/3/2012 12:43 AM, Mike Frysinger wrote: > > conversely, having a mount point removed from the perspective of > > userspace can be useful. like with tools that stubbornly enumerate all > > mounts, or attempting to shutdown your system with known unreachable > > network mounts. you, as the admin, know these things are gone and beyond > > accessible, so having the ability to remove them all manually and reboot > > cleanly (w/out ridiculous long retries/timeouts) is a good thing. > > If you want to hide mounts from certain processes, that is what unshare > is for. Hiding a mount from all processes does not make sense. If you > know a mount is gone and beyond recovery ( like in this loop over nfs > case, or removed media ), then it should be forcibly unmounted, not > simply made invisible and doomed to remain a zombie mount until the > system is rebooted. in an ideal world, maybe unshare might work. in the real world, it doesn't. you can use it only on *new* processes, not ones that are already running. nor can you do `unshare shutdown` and have it work since that simply signals a long running init process to initiate a shutdown. an nfs server goes afk and attempts to `umount` it timeout, as well as many desktop programs (like kde io daemons that like to walk available mount points) or shutdown processes. no call to `unshare` will fix this, but certainly forcibly removing it with `umount -l` will. -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
