这是一个非常酷的问题。
我有一个 python 脚本(main)，它调用一个 python 模块(foo.py)，而该模块又调用另一个 python 模块(barwrapper.py)，使用 LoadLibrary 动态打开和访问 libbar.so 库。
libbar 和整个链的其余部分打开并创建文件来执行其任务。当我们在主 python 脚本中发出 rmtree 来删除导入模块创建的临时目录时，问题就出现了。 rmtree 在脚本末尾、退出之前调用。调用失败，因为该目录包含 .nfs-whatever 隐藏文件，我猜这些文件是已删除的文件。这些文件显然在代码中保持打开状态，迫使 nfs 将它们移动到这些 .nfs-whatever 文件，直到文件描述符被释放。这种情况在其他文件系统中不会出现，因为与所保留的描述符关联的文件被有效地删除，但内核仍然可以访问，直到描述符关闭为止。
我们强烈怀疑 .so 库正在泄漏文件描述符，并且这些未关闭的文件在清理时破坏了 rmtree 派对。我考虑过在 barwrapper 中卸载 .so 文件，但显然没有办法做到这一点，而且我不确定 dynloader 是否会真正从进程空间中删除 lib 并关闭描述符，或者它是否只是将其标记为已卸载就是这样，等待被其他东西取代，但描述符已泄露。
我真的想不出解决该问题的其他解决方法(除了修复泄漏之外，这是我们不想做的事情，因为它是第 3 方库)。显然，它只发生在 nfs 上。您知道我们可以尝试修复它吗？
最佳答案
内核会跟踪文件描述符，因此即使你让 python 卸载 .so 并释放内存，它也不会知道关闭泄漏的文件描述符。唯一想到的是在 fork 后导入 .so，并且仅在 fork 子进程退出后进行清理(并且文件句柄在内核退出时隐式关闭)。
关于python - C 库中的文件句柄泄漏(也许)会给 NFS 带来麻烦(+python，但这是偶然的)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6048046/