关闭进程中所有打开的文件
如何找到进程中所有打开的文件（从进程内部）？
在 fork() 之后（在 exec() 之前）了解这一点似乎很有用。
我知道 getdtablesize() 和更可移植的 sysconf(_SC_OPEN_MAX) 的存在，但尝试关闭每个有效文件描述符似乎效率低下，无论其后面是否有打开的文件。 （我也意识到过早优化的危险，我想这更多是关于美学:-)
How do I find all the open files in a process (from inside itself)?
This seems useful to know after a fork() (before exec()).
I know of the existance of getdtablesize() and the more portable sysconf(_SC_OPEN_MAX), but it seems inefficient to attempt closing every valid file descriptor, whether there's an open file behind it or not. (I am also aware of the dangers of premature optimisation, this is more about aesthetics I guess :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您的程序将调用
fork和exec，您确实应该使用O_CLOEXEC标志打开所有文件描述符，这样您就不必手动在exec之前关闭它们。您还可以使用 fcntl 在打开文件后添加此标志，但这会受到多线程程序中的竞争条件的影响。If your program will be calling
forkandexec, you really should open all file descriptors with theO_CLOEXECflag so you don't have to manually close them beforeexec. You can also usefcntlto add this flag after a file is opened, but that's subject to race conditions in multithreaded programs.尝试关闭所有文件描述符可能听起来效率很低，但实际上并没有那么糟糕。如果系统性能良好的话，查找文件描述符的系统调用实现应该相当高效。
如果您只想查找关闭打开的文件描述符，您可以在存在 proc 文件系统的系统上使用它。例如，在 Linux 上，/proc/self/fd 将列出所有打开的文件描述符。迭代该目录，并关闭所有> 2的内容，不包括表示您正在迭代的目录的文件描述符。
It may sound inefficient to attempt to close all file descriptors, but it actually is not that bad. The system call implementation to lookup a file descriptor should be fairly efficient if the system is any good.
If you want to find only close the open file descriptors, you can use the proc filesystem on systems where it exists. E.g. on Linux, /proc/self/fd will list all open file descriptors. Iterate over that directory, and close everything >2, excluding the file descriptor that denotes the directory you are iterating over.
在支持它的系统上（基本上是指除 Linux 之外的任何 UNIX），有专门为此目的而设计的 closefrom(2) 系统调用。
On systems that support it (which basically means any unix other than Linux) there's the closefrom(2) system call, designed specifically for this purpose.
刚刚花了很多时间来追踪错误，是的，关闭所有文件描述符可能会导致问题。
问题是，有多少个文件描述符？
1024 曾经很常见，而且 1024 并不是一个完全不合理的要关闭的文件句柄数。由于它们中的大多数都是关闭的，因此这只是检查内存中的一个字节。
我的操作系统出厂时的默认值为 1,048,576。在这个（确实很慢）服务器上，尝试关闭文件句柄显然需要超过 4.7 微秒。这导致超时（5 秒）。而且目前还不清楚这个数字会增长到什么程度。至少设定一个（合理的）上限。
/proc/self/fd 并不理想，但像这样的错误很难找到。
Having just spent many hours tracking down a bug, yes, closing all file descriptors can cause problems.
The question is, how many file descriptors are there?
1024 used to be very common, and 1024 is not an entirely unreasonable number of file handles to close. Since most of them are closed, this is just checking a byte in memory.
My operating system ships with a default of 1,048,576. On this (admittedly slow) server, it apparently can take over 4.7 microseconds to try to close a filehandle. This resulted in a timeout (5 seconds). And there's no telling how high the number will grow. At least put a (reasonable) upper limit on it.
/proc/self/fd is not ideal, but bugs like this are very hard to find.