[ python-Bugs-1068268 ] subprocess is not EINTR-safe

[SourceForge.net]

Bugs item #1068268, was opened at 2004-11-17 13:07
Message generated for change (Comment added) made by timjr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 3
Private: No
Submitted By: Peter Åstrand (astrand)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess is not EINTR-safe

Initial Comment:
The subprocess module is not safe for use with signals,
because it doesn't retry the system calls upon EINTR.
However, as far as I understand it, this is true for
most other Python modules as well, so it isn't obvious
that the subprocess needs to be fixed. 

The problem was first noticed by John P Speno. 

----------------------------------------------------------------------

Comment By: Tim Daly, Jr. (timjr)
Date: 2007-07-26 21:14

Message:
Logged In: YES 
user_id=1854532
Originator: NO

I hit this in Python 2.5.1 on an Intel Mac in a PyQt application.  mpitt's
patch at
http://librarian.launchpad.net/6820347/subprocess-eintr-safety.patch fixed
it for me.


----------------------------------------------------------------------

Comment By: Martin Pitt (mpitt)
Date: 2007-03-15 01:57

Message:
Logged In: YES 
user_id=80975
Originator: NO

Updated patch:
http://librarian.launchpad.net/6820347/subprocess-eintr-safety.patch

I removed the _read_all() function, since that broke the 1 MB exception
limit and does not seem to be necessary in the first place.

----------------------------------------------------------------------

Comment By: Martin Pitt (mpitt)
Date: 2007-03-14 15:36

Message:
Logged In: YES 
user_id=80975
Originator: NO

I updated Peter's original patch to 2.5+svn fixes and added proper tests
to test_subprocess.py. It works great now.

What do you think about this approach? Fixing it only in submodule feels a
bit strange, but then again, this is meant to be an easy to use
abstraction, and most of the people that were hit by this (according to
Google) encountered the problem in subprocess.

I don't see how to attach something here, so I attached the updated patch
to the Ubuntu bug (https://launchpad.net/bugs/87292):

  http://librarian.launchpad.net/6807594/subprocess-eintr-safety.patch

Thanks,

Martin

----------------------------------------------------------------------

Comment By: Martin Pitt (mpitt)
Date: 2007-02-26 04:15

Message:
Logged In: YES 
user_id=80975
Originator: NO

I just got two different Ubuntu bug reports about this problem as well,
and I'm unsure how to circumvent this at the application level.

  http://librarian.launchpad.net/6514580/Traceback.txt
  http://librarian.launchpad.net/6527195/Traceback.txt

(from https://launchpad.net/bugs/87292 and its duplicate)

----------------------------------------------------------------------

Comment By: Matt Johnston (mattjohnston)
Date: 2004-12-21 23:07

Message:
Logged In: YES 
user_id=785805

I've hit this on a Solaris 9 box without explicitly using
signals. Using the DCOracle module, a seperate Oracle
process is executed. When this terminates, a SIGCHLD is sent
to the calling python process, which may be in the middle of
a select() in the communicate() call, causing EINTR. From
the output of truss (like strace), a sigchld handler doesn't
appear to be getting explicitly installed by the Oracle module.

SunOS 5.9 Generic_112233-01 sun4u sparc SUNW,Sun-Fire-280R

----------------------------------------------------------------------

Comment By: Peter Åstrand (astrand)
Date: 2004-11-17 13:15

Message:
Logged In: YES 
user_id=344921

One way of testing subprocess for signal-safeness is to
insert these lines just after _cleanup():

import signal
signal.signal(signal.SIGALRM, lambda x,y: 1)
signal.alarm(1)
import time
time.sleep(0.99)

Then run test_subprocess.py. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1068268&group_id=5470