Bug 859169 - sub processes ignore SIGPIPE
sub processes ignore SIGPIPE
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python (Show other bugs)
6.5
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Python Maintainers
BaseOS QE - Apps
:
Depends On: 1117751
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-20 13:29 EDT by Pádraig Brady
Modified: 2016-07-14 12:53 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 887194 1117751 (view as bug list)
Environment:
Last Closed: 2016-07-14 12:53:51 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Python 1652 None None None 2012-09-20 13:29:30 EDT

  None (edit)
Description Pádraig Brady 2012-09-20 13:29:30 EDT
Basically SIGPIPE is an often relied upon signal,
which should be reset to the default behavior before starting sub processes.
More details at http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009-07-02-python-sigpipe.html

The linked upstream issue has a patch that could be used,
and links the similar fix that has been applied to python 3.2
Comment 2 RHEL Product and Program Management 2012-12-14 03:38:39 EST
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 5 Bohuslav "Slavek" Kabrda 2014-02-14 05:37:00 EST
Padraig, would using a backported version of this (a separate module) [1] be an option for you? Also, if we do apply this patch, we will likely not change the default to not break anything, e.g. we'll use restore_sigpipe=False - we want to preserve the original behaviour.

[1] http://code.google.com/p/python-subprocess32/
Comment 6 Pádraig Brady 2014-05-26 06:35:30 EDT
Personally it's _very_ surprising that SIGPIPE is ignored.
I really can see that sub processes would be relying on that.
Much more likely that this is causing subtle issues for users.

If you want to be ultra conservative, then this should at
least be fixed for RHEL7.
Comment 7 Bohuslav "Slavek" Kabrda 2014-07-09 08:05:59 EDT
(In reply to Pádraig Brady from comment #6)
> Personally it's _very_ surprising that SIGPIPE is ignored.
> I really can see that sub processes would be relying on that.
> Much more likely that this is causing subtle issues for users.
> 
> If you want to be ultra conservative, then this should at
> least be fixed for RHEL7.

So, I'm not saying that this can't be done for RHEL 6. What I'm asking is:
- Is using subprocess32 module referenced in comment 5 a solution for you?
- Assuming we fix this issue, is it ok for you to explicitly specify restore_sigpipe=True? At this point and time, I'd probably not consider changing the default for RHEL 6.

Sorry for the late response, this got lost in my mailbox.
Comment 8 Pádraig Brady 2014-07-09 10:01:50 EDT
If not doing it by default then there is no point,
as the workaround is just about the same level of pain:
https://review.openstack.org/#/c/13346/2/nova/utils.py

subprocess32 is not an option for the same reason.
I.E. for those aware of the bug the workaround would
be easier than using subprocess32

So IMHO the decision is whether we want to fix this for python-2.6 or not.
Ignoring SIGPIPE is unusual so I can't see anyone depending on the existing behavior. But to be ultra conservative I suppose we could close this and only fix the RHEL 7 bug. I would strongly advise changing python-2.7 on rhel 7
Comment 9 Bohuslav "Slavek" Kabrda 2014-07-09 10:22:59 EDT
(In reply to Pádraig Brady from comment #8)
> If not doing it by default then there is no point,
> as the workaround is just about the same level of pain:
> https://review.openstack.org/#/c/13346/2/nova/utils.py
> 
> subprocess32 is not an option for the same reason.
> I.E. for those aware of the bug the workaround would
> be easier than using subprocess32
> 
> So IMHO the decision is whether we want to fix this for python-2.6 or not.
> Ignoring SIGPIPE is unusual so I can't see anyone depending on the existing
> behavior. But to be ultra conservative I suppose we could close this and
> only fix the RHEL 7 bug. I would strongly advise changing python-2.7 on rhel
> 7

Ok, thanks for the input.
I know that you think I'm being overly paranoid here, but [1] has taught me that even adding an argument (with default set to "don't do anything about this") to function can break lots of depending software. As noted above, I'm not saying this can't be done for RHEL 6. We'll try to come up with patch for RHEL 7 (where I think such change is acceptable right now) - as noted in bug 1117751 comment 2. We'll then try to investigate in depth what could break if we backported this patch to RHEL 6 and we'll see. I'm afraid I can't give you a better answer right now.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=958868
Comment 10 Bohuslav "Slavek" Kabrda 2014-11-25 02:13:48 EST
Making this bug depend on bug 1117751, this has to get fixed in RHEL 7 first to not introduce regressions.
Comment 11 Bohuslav "Slavek" Kabrda 2015-01-07 09:09:43 EST
Since it seems this won't be fixed for 7.1 in RHEL 7, I'm moving this bug to 6.8.
Comment 13 Petr Viktorin 2016-07-14 12:53:51 EDT
The current behavior is not ideal, but the fix introduces regressions, and a workaround is available for software that needs the reset functionality.
Therefore, I unfortunately need to close this as WONTFIX.


For discussion, see bug #1117751

Note You need to log in before you can comment on or make changes to this bug.