bash 如何从 unix 系统中的另一个进程关闭文件描述符

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/323146/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-09 17:48:23  来源:igfitidea点击:

How to close a file descriptor from another process in unix systems

bashunixfilefile-descriptorlsof

提问by Seb

You can use command lsofto get file descriptors for all running processes, but what I would like to do is to close some of those descriptors without being inside that process. This can be done on Windows, so you can easily unblock some application.

您可以使用命令lsof来获取所有正在运行的进程的文件描述符,但我想要做的是关闭其中一些描述符而不进入该进程。这可以在 Windows 上完成,因此您可以轻松取消阻止某些应用程序。

Is there any command or function for that?

是否有任何命令或功能?

采纳答案by Windows programmer

In Windows you can use a program to do it because someone wrote a program that inserts a device driver into the running kernel to do it. By the way it can be dangerous to do this, because after you close a handle that a broken application was using, the application doesn't know that the handle was closed, and when the application opens some other unrelated object it doesn't know that the same handle might now refer to some other unrelated object. You really want to kill the broken application as soon as possible.

在 Windows 中,您可以使用程序来执行此操作,因为有人编写了一个程序,将设备驱动程序插入正在运行的内核中来执行此操作。顺便说一句,这样做可能很危险,因为在关闭损坏的应用程序正在使用的句柄后,应用程序不知道该句柄已关闭,并且当应用程序打开其他一些不相关的对象时,它也不知道同一个句柄现在可能引用其他一些不相关的对象。您真的想尽快终止损坏的应用程序。

In Linux surely you can use the same kind of technique. Write a program that inserts a module into the running kernel. Communicate with the module and tell it which handles to close. It will be equally dangerous to do so.

在 Linux 中你当然可以使用同样的技术。编写一个程序,将一个模块插入到正在运行的内核中。与模块通信并告诉它关闭哪个句柄。这样做同样危险。

回答by Andreas

I don't know why you are trying to do this, but you should be able to attach to the process using gdb and then call close() on the fd. Example:

我不知道您为什么要这样做,但是您应该能够使用 gdb 附加到进程,然后在 fd 上调用 close()。例子:

In one shell: cat

一壳:猫

In another shell:

在另一个外壳中:

$pidof cat
7213

$gdb -p 7213

...
lots of output
...

(gdb)

Now you tell gdb to execute close(0):

现在你告诉 gdb 执行 close(0):

(gdb) p close(0)

 = 0

(gdb) c

Continuing.

Program exited with code 01.
(gdb)

In the first shell I get this output:

在第一个 shell 中,我得到以下输出:

cat: -: Bad file descriptor

cat: closing standard input: Bad file descriptor

回答by Fernando Miguélez

I don't think so but lsof gives you the PID of the process that has opened the file, so what you can do is entirely kill the process or at least send a signal to let it exit.

我不这么认为,但是 lsof 为您提供了打开文件的进程的 PID,因此您可以做的是完全终止该进程或至少发送一个信号让它退出。

回答by unwind

I doubt it. File descriptors are process-local, stdoutis 1 to all processes, yet they still reference unique streams of course.

我对此表示怀疑。文件描述符是进程本地的,stdout对所有进程都是 1,但它们当然仍然引用唯一的流。

Perhaps more detail would be useful, about the blocking problem you're trying to solve.

也许更多的细节会很有用,关于你试图解决的阻塞问题。

回答by CesarB

There is much less need to do this on Unix than on Windows.

在 Unix 上执行此操作的需要比在 Windows 上少得多。

On Windows, most programs tend to "lock" (actually deny sharing) the files they open, so they cannot be read/written/deleted by another program.

在 Windows 上,大多数程序倾向于“锁定”(实际上是拒绝共享)它们打开的文件,因此其他程序无法读取/写入/删除它们。

On Unix, most of the time this does not happen. File locking on Unix is mostly advisory, and will only block other locking attempts, not normal read/write/delete operations. You can even remove the current directory of a process.

在 Unix 上,大多数情况下不会发生这种情况。Unix 上的文件锁定主要是建议性的,只会阻止其他锁定尝试,而不是正常的读/写/删除操作。您甚至可以删除进程的当前目录。

About the only situation this comes up in normal usage in Unix is when trying to umount a filesystem (any reference at all to the mounted filesystem can block the umount).

关于在 Unix 中正常使用时出现的唯一情况是尝试卸载文件系统时(对已安装文件系统的任何引用都可能阻止卸载)。