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: Subprocess: Popen'ed children hang due to open pipes
Type: behavior Stage: test needed
Components: Library (Lib) Versions: Python 3.1, Python 2.7
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: BreamoreBoy, boye, giampaolo.rodola, r.david.murray, rosslagerwall
Priority: normal Keywords:

Created on 2008-10-13 10:36 by boye, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg74680 - (view) Author: Boye Høverstad (boye) Date: 2008-10-13 10:36
subprocess.Popen.wait() hangs if you have spawned multiple child
processes that do not terminate until their standard input is closed
('cat' is example of such a process).  This happens on POSIX platforms.
 I'm using Python 2.5.1, but I believe the issue is present in the SVN
trunk version of subprocess as well.

Here is a test program:
--------------------------
import subprocess, sys

p1 = subprocess.Popen("cat", bufsize=0, stdin=subprocess.PIPE)
p2 = subprocess.Popen("cat", bufsize=0, stdin=subprocess.PIPE)

p1.stdin.close()
ret = p1.wait()
print >>sys.stderr, "Child 1 wait completed with ret", ret

p2.stdin.close()
ret = p2.wait()
print >>sys.stderr, "Child 2 wait completed with ret", ret, "Bye bye"
--------------------------

The call to p1.wait() will never return.  If p2.wait is called first,
the program terminates cleanly.

p1 never terminates because p1.stdin is duplicated in the (second) child
process when the parent process forks as part of the call to p2 =
subprocess.Popen().  The line p1.stdin.close() thus has no effect.

I am not sure whether this is a bug or deliberate design, but the
behavior above seems a bit weird to me, and it took me quite some time
to figure out what happened.  However, the proposed fix below of course
has side effects that may be undesirable.

wait() will not hang if  the "close on exec" flag is set on the
subprocess pipes.  Conveniently, the method _set_cloexec_flag already
exists to do this, so the fix amounts to calling this from
Popen._get_handles:

elif stdin == PIPE:
    p2cread, p2cwrite = os.pipe()
    self._set_cloexec_flag(p2cwrite)

The last line is the added one, similar lines must be added for stdout
and stderr.

Alternatively, the test program above will terminate cleanly if
"p1._set_cloexec_flag(p1.stdin)" is added before the creation of p2.
msg109592 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-07-08 20:29
Would someone with knowledge of subprocess please comment on this.
msg110209 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-07-13 16:03
The suggestion looks reasonable to me, and the current behavior does not look like an intentional design.

Boye, would you be interested in proposing a patch with unit tests?
msg125987 - (view) Author: Ross Lagerwall (rosslagerwall) (Python committer) Date: 2011-01-11 09:08
This issue has been fixed on 3.2.
msg133045 - (view) Author: Ross Lagerwall (rosslagerwall) (Python committer) Date: 2011-04-05 16:18
This has been fixed with all the subprocess improvements in between 3.1 and 3.2 but the decision has been taken (msg125910) not to backport the fix to 3.1 and 2.7 which would involve a C extension.

However, a workaround on 2.7 and 3.1 is to set close_fds=True.

Closing as "wont fix".
History
Date User Action Args
2022-04-11 14:56:40adminsetgithub: 48362
2011-04-05 16:18:31rosslagerwallsetstatus: open -> closed
resolution: wont fix
messages: + msg133045
2011-01-11 15:48:38giampaolo.rodolasetnosy: + giampaolo.rodola
2011-01-11 09:08:56rosslagerwallsetnosy: + rosslagerwall

messages: + msg125987
versions: - Python 3.2
2010-07-13 16:03:11r.david.murraysetversions: + Python 2.7, Python 3.2
nosy: + r.david.murray

messages: + msg110209

stage: test needed
2010-07-08 20:29:19BreamoreBoysetnosy: + BreamoreBoy
messages: + msg109592
2008-10-13 10:36:18boyecreate