C库中的文件句柄泄漏（也许）使NFS产生了麻烦（+ python，但这是偶然的）

| 这是一个很酷的问题。 我有一个python脚本（主要），该脚本调用一个python模块（foo.py），该模块依次调用另一个python模块（barwrapper.py），该模块使用LoadLibrary动态打开和访问libbar.so库。 libbar和整个链的其余部分将打开并创建文件以执行其任务。当我们在主python脚本中发出rmtree来摆脱由导入的模块创建的临时目录时，就会出现问题。 rmtree在脚本末尾（即将退出之前）被调用。调用失败，因为该目录包含“ 0”个隐藏文件，我想这是已删除的文件。这些文件显然在代码中保持打开状态，迫使nfs将它们移动到这些“ 0”文件中，直到释放文件描述符为止。在其他文件系统中不会发生这种情况，因为与保留的描述符关联的文件已被有效删除，但在关闭描述符之前，内核一直可以访问。 我们强烈怀疑.so库正在泄漏​​文件描述符，并且这些未关闭的文件在清理时破坏了rmtree方。我曾考虑过在Barwrapper中卸载.so文件，但是显然没有办法做到这一点，而且我不确定dynloader是否会从进程空间中真正删除lib并关闭描述符，或者是否只是将其标记为已卸载，仅此而已，正等待其他内容替换，但描述符已泄漏。 我真的想不出解决该问题的其他方法（除了修复泄漏，我们不想做的事情，因为它是第三方库）。显然，它仅在nfs上发生。您有任何想法我们可以尝试修复它吗？