In many situations you need e.g. umount a file system and you do NOT want to close applications which have files open on this file system. Currently there's no way to umount such an FS unless you close all those "offending" applications.
This is absolutely inconvenient, because
1) In a multiuser environment you may not want to close applications running under a different user account - you want to keep them running.
2) Finding such applications should not be a concern for a root user (yes, I known about fuser).
There must be no concern about "lost" file descriptors because applications must have a logic to deal with such a situation (and I am quite sure most applications have it).
neverending revoke(2) story
last attempt was broken by necessity to audit every ioctl handler wrt
this behaviour, IIRC
Alexey, could you please shed some light on this topic? It seems like some BSD's have this system call, but I don't see it neither in linux nor in glibc.
search linux-kernel archives for "revoke"
several attempts with different degrees of brokeness
Hm, I've found a long thread here http://lkml.org/lkml/2009/6/1/395 and it seems like it ended to no effect. (google for [PATCH 04/23] vfs: Introduce infrastructure for revoking a file )
OK, let's wait for a better approach - I'm not a developer/programmer, so I can only hope Linux will have a revoke (2) system call (which is a must nowadays, IMO).
A better solution is avaliable from Al viro....I got stuck up in this bug for some time
It's not yet a solution, it's just a proposal and from what it looks like, it seems like half of the kernel needs to be rewritten from scratch in order to accommodate this call.
Yeah I m just one patch old in hacking..desperate to get one more in...I think i landed up in the wrong place...:P
Is maybe `umount --lazy` (perhaps even coupled with `--recursive` if necessary) doing wonders for anyone else?
Lazy unmount. Detach the filesystem from the file hierarchy
now, and clean up all references to this filesystem as soon as
it is not busy anymore.
A system reboot would be expected in near future if you're going
to use this option for network filesystem or local filesystem
with submounts. The recommended use-case for umount -l is to
prevent hangs on shutdown due to an unreachable network share
where a normal umount will hang due to a downed server or a net‐
work partition. Remounts of the share will not be possible.
Recursively unmount each specified directory. Recursion for
each directory will stop if any unmount operation in the chain
fails for any reason. The relationship between mountpoints is
determined by /proc/self/mountinfo entries. The filesystem must
be specified by mountpoint path; a recursive unmount by device
name (or UUID) is unsupported.
(In reply to howaboutsynergy from comment #8)
> Is maybe `umount --lazy` (perhaps even coupled with `--recursive` if
> necessary) doing wonders for anyone else?
This system call is _not_ about being able to unmount devices.