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.

Author gregory.p.smith
Recipients cvrebert, ezio.melotti, gregory.p.smith, pitrou, rosslagerwall, sarum9in
Date 2012-08-29.08:32:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
easy enough to reproduce...

$ ./python.exe -c 'import os, subprocess as s; os.close(0); os.close(1); s.Popen(["/bin/true"])'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/Users/gps/python/hg/default/Lib/", line 818, in __init__
    restore_signals, start_new_session)
  File "/Users/gps/python/hg/default/Lib/", line 1363, in _execute_child
    restore_signals, start_new_session, preexec_fn)
ValueError: errpipe_write must be >= 3

Examining the code, it looks like that restriction is to prevent the dup2's for any passed in stdin, stdout or stderr pipes from overwriting errpipe_write in Modules/_posixsubprocess.c's child_exec() function.

First guess at a fix: child_exec() needs to detect this situation and dup(errpipe_write) until it gets a fd not in the 0..2 range before the dup2(...) calls that could otherwise blindly clobber it.  This could possibly be done by the parent process's _create_pipe() in Lib/ when allocating the errpipe_read and errpipe_write fds.

Suggested Workaround: for now for any code running into this (Python daemons launching subprocesses?) - Call os.pipe() twice at the start of your program to burn 4 fds.  That'll guarantee 0, 1 and 2 will not be used for this pipe.
Date User Action Args
2012-08-29 08:32:32gregory.p.smithsetrecipients: + gregory.p.smith, pitrou, ezio.melotti, cvrebert, rosslagerwall, sarum9in
2012-08-29 08:32:32gregory.p.smithsetmessageid: <>
2012-08-29 08:32:31gregory.p.smithlinkissue15798 messages
2012-08-29 08:32:29gregory.p.smithcreate