|Summary:||Linux kernel needs an API for forcibly closing open file descriptors, i.e. revoke (2) system call|
|Product:||File System||Reporter:||Artem S. Tashkinov (aros)|
|Severity:||enhancement||CC:||adobriyan, alan, howaboutsynergy, marshel.abraham, szg00000|
|Kernel Version:||All known (inc 3.5rc2)||Tree:||Mainline|
Description Artem S. Tashkinov 2009-10-29 08:01:24 UTC
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).
Comment 1 Alexey Dobriyan 2009-11-16 15:07:56 UTC
neverending revoke(2) story last attempt was broken by necessity to audit every ioctl handler wrt this behaviour, IIRC
Comment 2 Artem S. Tashkinov 2009-11-16 15:15:49 UTC
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.
Comment 3 Alexey Dobriyan 2009-11-16 15:18:17 UTC
search linux-kernel archives for "revoke" several attempts with different degrees of brokeness
Comment 4 Artem S. Tashkinov 2009-11-16 15:42:47 UTC
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).
Comment 5 Marshel Abraham 2013-05-30 08:37:59 UTC
A better solution is avaliable from Al viro....I got stuck up in this bug for some time http://lwn.net/Articles/546540/
Comment 6 Artem S. Tashkinov 2013-05-30 12:33:04 UTC
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.
Comment 7 Marshel Abraham 2013-05-30 13:57:50 UTC
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
Comment 8 GYt2bW 2019-05-06 21:06:47 UTC
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. ```
Comment 9 Artem S. Tashkinov 2019-05-06 22:00:32 UTC
(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.
Comment 10 Artem S. Tashkinov 2020-08-05 10:05:03 UTC
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?