Question

我有一个长期运行的python项目，它使用子进程模块启动各种其他程序。它等待每个程序完成，然后结束包装函数并返回其等待循环。

最终，这会使正在运行的计算机停止运行，错误是没有更多的文件描述符可用。

我无法在subprocess docs中的任何地方找到子进程关闭时文件描述符会发生什么。起初，我以为它们会自动关闭，因为subprocess.call（）命令会一直等到子节点终止。

但如果是这种情况我就不会有问题。我还认为如果还有剩下的东西，python会在函数完成时进行垃圾收集，并且文件描述符超出范围。但这似乎也不是这样。

如何访问这些文件描述符？ subprocess.call（）函数只返回退出代码，而不是打开文件描述符。我在这里还有其他的东西吗？

此项目充当各种企业应用程序之间的粘合剂。所述应用程序不能流水线化，它们是gui系统。所以，我唯一能做的就是用内置宏启动它们。这些宏输出文本文件，我将其用于管道中的下一个程序。

是的，它听起来一样糟糕。幸运的是，所有文件最终都有非常独特的名字。因此，在接下来的几天里，我将使用下面建议的sys internals工具来尝试跟踪文件。我会告诉你结果如何。

我没有打开大多数文件，我只是使用win32file.CopyFile（）函数移动它们。

Answer 1

我遇到了同样的问题。

我们经常使用subprocess.Popen（）来调用Windows环境中的外部工具。在某些时候，我们遇到了一个问题，即没有更多的文件描述符可用。我们深入研究了这个问题，发现subprocess.Popen实例在Windows中的行为与在Linux中的行为不同。

如果Popen实例没有被销毁（例如通过以某种方式保留引用，因此不允许垃圾收集器销毁对象），在调用期间创建的管道仍然在Windows中打开，而在Linux中它们是自动的在Popen.communicate（）被调用后关闭。如果在进一步调用中继续这样做，管道中的“僵尸”文件描述符将堆积起来，最终导致Python异常IOError: [Errno 24] Too many open files。

如何在Python中获取打开的文件描述符

为了让我们解决问题，我们需要一种在Python脚本中获取有效文件描述符的方法。因此，我们制作了以下脚本。请注意，我们只检查0到100之间的文件描述符，因为我们不会同时打开这么多文件。

fd_table_status.py ：

import os
import stat

_fd_types = (
    ('REG', stat.S_ISREG),
    ('FIFO', stat.S_ISFIFO),
    ('DIR', stat.S_ISDIR),
    ('CHR', stat.S_ISCHR),
    ('BLK', stat.S_ISBLK),
    ('LNK', stat.S_ISLNK),
    ('SOCK', stat.S_ISSOCK)
)

def fd_table_status():
    result = []
    for fd in range(100):
        try:
            s = os.fstat(fd)
        except:
            continue
        for fd_type, func in _fd_types:
            if func(s.st_mode):
                break
        else:
            fd_type = str(s.st_mode)
        result.append((fd, fd_type))
    return result

def fd_table_status_logify(fd_table_result):
    return ('Open file handles: ' +
            ', '.join(['{0}: {1}'.format(*i) for i in fd_table_result]))

def fd_table_status_str():
    return fd_table_status_logify(fd_table_status())

if __name__=='__main__':
    print fd_table_status_str()

简单地运行时，它将显示所有打开的文件描述符及其各自的类型：

$> python fd_table_status.py
Open file handles: 0: CHR, 1: CHR, 2: CHR
$>

通过Python代码调用fd_table_status_str（），输出相同。有关“CHR”和尊重“短代码”含义的详细信息，请参阅Python documentation on stat。

测试文件描述符行为

尝试在Linux和Windows中运行以下脚本：

test_fd_handling.py ：

import fd_table_status
import subprocess
import platform

fds = fd_table_status.fd_table_status_str

if platform.system()=='Windows':
    python_exe = r'C:\Python27\python.exe'
else:
    python_exe = 'python'

print '1) Initial file descriptors:\n' + fds()
f = open('fd_table_status.py', 'r')
print '2) After file open, before Popen:\n' + fds()
p = subprocess.Popen(['python', 'fd_table_status.py'],
                     stdin=subprocess.PIPE,
                     stdout=subprocess.PIPE,
                     stderr=subprocess.PIPE)
print '3) After Popen, before reading piped output:\n' + fds()
result = p.communicate()
print '4) After Popen.communicate():\n' + fds()
del p
print '5) After deleting reference to Popen instance:\n' + fds()
del f
print '6) After deleting reference to file instance:\n' + fds()
print '7) child process had the following file descriptors:'
print result[0][:-1]

Linux输出

1) Initial file descriptors:
Open file handles: 0: CHR, 1: CHR, 2: CHR
2) After file open, before Popen:
Open file handles: 0: CHR, 1: CHR, 2: CHR, 3: REG
3) After Popen, before reading piped output:
Open file handles: 0: CHR, 1: CHR, 2: CHR, 3: REG, 5: FIFO, 6: FIFO, 8: FIFO
4) After Popen.communicate():
Open file handles: 0: CHR, 1: CHR, 2: CHR, 3: REG
5) After deleting reference to Popen instance:
Open file handles: 0: CHR, 1: CHR, 2: CHR, 3: REG
6) After deleting reference to file instance:
Open file handles: 0: CHR, 1: CHR, 2: CHR
7) child process had the following file descriptors:
Open file handles: 0: FIFO, 1: FIFO, 2: FIFO, 3: REG

Windows输出

1) Initial file descriptors:
Open file handles: 0: CHR, 1: CHR, 2: CHR
2) After file open, before Popen:
Open file handles: 0: CHR, 1: CHR, 2: CHR, 3: REG
3) After Popen, before reading piped output:
Open file handles: 0: CHR, 1: CHR, 2: CHR, 3: REG, 4: FIFO, 5: FIFO, 6: FIFO
4) After Popen.communicate():
Open file handles: 0: CHR, 1: CHR, 2: CHR, 3: REG, 5: FIFO, 6: FIFO
5) After deleting reference to Popen instance:
Open file handles: 0: CHR, 1: CHR, 2: CHR, 3: REG
6) After deleting reference to file instance:
Open file handles: 0: CHR, 1: CHR, 2: CHR
7) child process had the following file descriptors:
Open file handles: 0: FIFO, 1: FIFO, 2: FIFO

正如您在步骤4中看到的那样，Windows的行为与Linux不同。必须销毁Popen实例才能关闭管道。

顺便说一下，步骤7中的差异显示了与Windows中Python解释器行为有关的不同问题，您可以看到有关这两个问题的更多详细信息here。

Answer 2

你使用的是什么python版本？有一个已知的subprocess.Popen（）文件描述符泄漏也可能影响subprocess.call（）

http://bugs.python.org/issue6274

正如您所看到的，这只在python-2.6中修复了

Answer 3

在重大重构之后问题就消失了，所以我在这里要注意的是，我遇到的部分问题是为python寻找内存调试工具。

此后我发现了heapy。

Answer 4

文件描述符会在进程执行时消失，因此它必须是保留文件描述符的父级（您可以使用lsof验证这一点）。父母的代码是做什么的？

Python子进程耗尽文件描述符

4 个答案:

如何在Python中获取打开的文件描述符

测试文件描述符行为