使用Subprocess Popen的类库困挠了我一个月的问题终于解决了。
一句话就是：等待命令返回不要使用
wait()，而是使用communicate()，但注意内存，大输出使用文件。
错误的使用例子
之前的代码这样使用的。
# 不合适的代码
def run_it(self, cmd):
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True,
stderr=subprocess.PIPE, close_fds=True)
log.debug('running:%s' % cmd)
p.wait()
if p.returncode != 0:
log.critical("Non zero exit code:%s executing: %s" % (p.returncode, cmd))
return p.stdout
这段代码之前用着一直没有问题的，后来不知道为何就不能用了（后面知道了，原来输出内容增加，输出的问题本太长，把管道给堵塞了）。
这样的代码也在之前的一个项目中使用，而且调用的次数有上亿次，也没什么问题。之前倒是也卡住了一次，不过有个大神把问题找到了，因为Python版本低于2.7.6，Python对close_fds的一些实现不太好导致的，没有把管道释放掉，一直卡住。设置close_fds=True。不过这个并没有解决我的问题。
解决了我的问题
当时想着既然卡住了，那我就看看是输出了什么才卡住的，结果现有的代码无法支持我的想法，就换了代码，没想到就不卡住了。
def run_it(cmd):
# _PIPE = subprocess.PIPE
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True,
stderr=subprocess.PIPE) #, close_fds=True)
log.debug('running:%s' % cmd)
out, err = p.communicate()
log.debg(out)
if p.returncode != 0:
log.critical("Non zero exit code:%s executing: %s" % (p.returncode, cmd))
return p.stdout
Warning
Use communicate() rather than .stdin.write, .stdout.read or .stderr.read to avoid deadlocks due to any of the other OS pipe buffers filling up and blocking the child process.
Popen.wait()
Wait for child process to terminate. Set and return returncode attribute.
Warning This will deadlock when using stdout=PIPE and/or stderr=PIPE and the child process generates enough output to a pipe such that it blocks waiting for the OS pipe buffer to accept more data. Use communicate() to avoid that.
Popen.communicate(input=None)
Interact with process: Send data to stdin. Read data from stdout and stderr, until end-of-file is reached. Wait for process to terminate. The optional input argument should be a string to be sent to the child process, or None, if no data should be sent to the child.
communicate() returns a tuple (stdoutdata, stderrdata).
Note that if you want to send data to the process’s stdin, you need to create the Popen object with stdin=PIPE. Similarly, to get anything other than None in the result tuple, you need to give stdout=PIPE and/or stderr=PIPE too.
Note The data read is buffered in memory, so do not use this method if the data size is large or unlimited.
之前没注意，再细看一下文档，感觉豁然开朗。
Linux管道限制，为什么会阻塞呢？
下面来看看Can someone explain pipe buffer deadlock?的回答。
子进程产生一些数据，他们会被buffer起来，当buffer满了，会写到子进程的标准输出和标准错误输出，这些东西通过管道发送给父进程。当管道满了之后，子进程就停止写入，于是就卡住了。
及时取走管道的输出也没有问题
# 及时从管道中取走数据
def run_it(self, cmd):
p = subprocess.Popen(cmd, stdout=subprocess.PIPE, shell=True,
stderr=subprocess.PIPE, close_fds=True)
log.debug('running:%s' % cmd)
for line in iter(p.stdout.readline, b''):
print line, # print to stdout immediately
p.stdout.close()
p.wait()
if p.returncode != 0:
log.critical("Non zero exit code:%s executing: %s" % (p.returncode, cmd))
return p.stdout
看了Python的communicate()内部就是将stdout/stderr读取出来到一个list变量中的，最后函数结束时返回。
测试Linux管道阻塞问题
看到别人的例子，一直在想怎么测试输出64K的数据，发现dd这个思路很棒，是见过最优雅的例子了，精确控制输出的长度，其他都是从某些地方搞来大文件导入进来。
#!/usr/bin/env python # coding: utf-8 # yc@2013/04/28 import subprocess def test(size): print 'start' cmd = 'dd if=/dev/urandom bs=1 count=%d 2>/dev/null' % size p = subprocess.Popen(args=cmd, shell=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT, close_fds=True) #p.communicate() p.wait() # 这里超出管道限制，将会卡住子进程 print 'end' # 64KB test(64 * 1024) # 64KB + 1B test(64 * 1024 + 1) # output : start end start # 然后就阻塞了。
首先测试输出为 64KB 大小的情况。使用 dd 产生了正好 64KB 的标准输出，由 subprocess.Popen 调用，然后使用 wait() 等待 dd 调用结束。可以看到正确的 start 和 end 输出；然后测试比 64KB 多的情况，这种情况下只输出了 start，也就是说程序执行卡在了 p.wait() 上，程序死锁。
总结
那死锁问题如何避免呢？官方文档里推荐使用 Popen.communicate()。这个方法会把输出放在内存，而不是管道里，所以这时候上限就和内存大小有关了，一般不会有问题。而且如果要获得程序返回值，可以在调用 Popen.communicate() 之后取 Popen.returncode 的值。
但真的如果超过内存了，那么要考虑比如文件 stdout=open("process.out", "w") 的方式来解决了，不能使用管道了。
另外说一下。管道的要用清楚，不要随意的乱世用管道。比如没有input的时候，那么stdin就不要用管道了。
还有不要把简单的事情复杂化。比如echo 1 > /sys/linux/xxx修改文件，这么简单的功能就不要用Linux的shell调用了，使用Python自带的 open('file', 'w').write('1')。尽量保持Python范。