This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: when piping output between subprocesses some fd is left open blocking forever
Type: behavior Stage:
Components: Library (Lib) Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: duplicate
Dependencies: Superseder: subprocess leaks open file descriptors between Popen instances causing hangs
View: 7213
Assigned To: Nosy List: nosklo, steven.k.wong
Priority: normal Keywords:

Created on 2009-12-06 17:07 by nosklo, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (2)
msg96032 - (view) Author: Clovis Fabricio (nosklo) * Date: 2009-12-06 17:07
Suppose I want to simulate the following shell pipe using the subprocess
module:

`grep -v not | cut -c 1-10`

The documentation example here
http://docs.python.org/library/subprocess.html#replacing-shell-pipeline
Implies that I want to run this:

grep_process = Popen(["grep", "-v", "not"], stdin=PIPE, stdout=PIPE)
cut_process = Popen(["cut", "-c", "1-10"], stdin=p1.stdout, stdout=PIPE)
grep_process.stdin.write('Hello World\n')
grep_process.stdin.close()
result = cut_process.stdout.read() # blocks forever here
assert result == "Hello Worl\n"

When grep_prcoess starts, two file descriptors are created, one 
for each end of the pipe. Lets call those `grep-stdin-w` and
`grep-stdout-r`.
When I run cut_process, `grep-stdout-r` gets passed as cut_process sdtin. 
Since `close_fds=False` by default, The effect of that is that
cut_process also 
inherits `grep-stdin-w`. So `grep` can't die even if I explicty run
`grep_process.stdin.close()`
because `grep-stdin-w` stdin is still inside cut_process (`cut` ignores
the extra open fd).

Passing `close_fds=True` to the second Popen call makes the code work
perfectly.
`close_fds=True` should be the default on unix systems, because it
closes files descriptors that have nothing to do with the process, leaving
stdin, stdout and stderr working, which is the intended behaviour of
most code.
msg97605 - (view) Author: Steven K. Wong (steven.k.wong) Date: 2010-01-11 20:56
Looks like a duplicate of http://bugs.python.org/issue7213 .
History
Date User Action Args
2022-04-11 14:56:55adminsetgithub: 51697
2010-01-11 21:03:42floxsetstatus: open -> closed
resolution: duplicate
superseder: subprocess leaks open file descriptors between Popen instances causing hangs
2010-01-11 20:56:30steven.k.wongsetnosy: + steven.k.wong
messages: + msg97605
2009-12-06 17:07:45nosklocreate