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 http://lwn.net/Articles/546540/
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? ``` -l, --lazy 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. -R, --recursive 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.
Is this the same or not? http://lkml.iu.edu/hypermail/linux/kernel/2008.0/02649.html https://lkml.org/lkml/2020/8/4/385 And how come the patch is so small?