如何从 UNIX 系统中的另一个进程关闭文件描述符
您可以使用命令lsof来获取所有正在运行的进程的文件描述符，但我想做的是关闭其中一些描述符而不进入该进程。 这可以在 Windows 上完成，因此您可以轻松解锁某些应用程序。
有什么命令或功能吗？
You can use command lsof to 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.
Is there any command or function for that?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我不知道你为什么要尝试这样做，但你应该能够使用 gdb 附加到进程，然后在 fd 上调用 close() 。 示例：
在一个 shell 中： cat
在另一个 shell 中：
现在告诉 gdb 执行 close(0)：
在第一个 shell 中，我得到以下输出：
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:
In one shell: cat
In another shell:
Now you tell gdb to execute close(0):
In the first shell I get this output:
我不这么认为，但是 lsof 会给你打开文件的进程的 PID，所以你能做的就是完全终止该进程，或者至少发送一个信号让它退出。
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.
在 Windows 中，您可以使用程序来完成此操作，因为有人编写了一个程序，将设备驱动程序插入正在运行的内核中来完成此操作。 顺便说一句，这样做可能很危险，因为在关闭损坏的应用程序正在使用的句柄后，应用程序不知道该句柄已关闭，并且当应用程序打开其他一些不相关的对象时，它也不知道同一个句柄现在可能引用一些其他不相关的对象。 您确实想尽快杀死损坏的应用程序。
在 Linux 中你当然可以使用同样的技术。 编写一个程序，将模块插入到正在运行的内核中。 与模块通信并告诉它关闭哪个句柄。 这样做同样危险。
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.
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.
我对此表示怀疑。 文件描述符是进程本地的，stdout 对于所有进程都是 1，但它们当然仍然引用唯一的流。
也许更多关于您试图解决的阻塞问题的细节会很有用。
I doubt it. File descriptors are process-local,
stdoutis 1 to all processes, yet they still reference unique streams of course.Perhaps more detail would be useful, about the blocking problem you're trying to solve.
在 Unix 上这样做的需要比在 Windows 上少得多。
在 Windows 上，大多数程序倾向于“锁定”（实际上拒绝共享）它们打开的文件，因此其他程序无法读取/写入/删除它们。
在 Unix 上，大多数情况下不会发生这种情况。 Unix 上的文件锁定主要是建议性的，并且只会阻止其他锁定尝试，而不是正常的读/写/删除操作。 您甚至可以删除进程的当前目录。
在 Unix 中正常使用时出现的唯一情况是尝试卸载文件系统时（对已安装文件系统的任何引用都可能阻止卸载）。
There is much less need to do this on Unix than on 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.
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.
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).