关闭进程中所有打开的文件答案

【问题标题】：Closing all open files in a process关闭进程中所有打开的文件
【发布时间】：2010-11-21 20:54:16
【问题描述】：

如何（从自身内部）找到进程中所有打开的文件？

在fork() 之后（exec() 之前）知道这似乎很有用。

我知道getdtablesize() 和更便携的sysconf(_SC_OPEN_MAX) 的存在，但是尝试关闭每个有效文件描述符似乎效率低下，无论其后面是否有打开的文件。（我也意识到过早优化的危险，我猜这更多是关于美学:-)

【问题讨论】：

【解决方案1】：

如果您的程序将调用fork 和exec，您确实应该使用O_CLOEXEC 标志打开所有文件描述符，这样您就不必在exec 之前手动关闭它们。您也可以在打开文件后使用fcntl 添加此标志，但这会受到多线程程序中的竞争条件的影响。

【讨论】：

【解决方案2】：

尝试关闭所有文件描述符可能听起来效率低下，但实际上并没有那么糟糕。如果系统好的话，查找文件描述符的系统调用实现应该是相当有效的。

如果你只想找到关闭打开的文件描述符，你可以在它存在的系统上使用 proc 文件系统。例如。在 Linux 上，/proc/self/fd 将列出所有打开的文件描述符。遍历该目录，然后关闭所有 >2 的内容，不包括表示您正在遍历的目录的文件描述符。

【讨论】：

【解决方案3】：

在支持它的系统上（基本上是指 Linux 以外的任何 unix），有 closefrom(2) 系统调用，专门为此目的而设计。

【讨论】：

【解决方案4】：

刚刚花了很多时间来追踪一个错误，是的，关闭所有文件描述符可能会导致问题。

问题是，有多少个文件描述符？

1024 曾经很常见，1024 并不是一个完全不合理的要关闭的文件句柄数。由于大部分是关闭的，这只是检查内存中的一个字节。

我的操作系统出厂时默认值为 1,048,576。在这个（诚然很慢）服务器上，尝试关闭文件句柄显然可能需要超过 4.7 微秒。这导致超时（5 秒）。并且不知道这个数字会增长多高。至少给它一个（合理的）上限。

/proc/self/fd 并不理想，但是这样的 bug 很难找到。

【讨论】：