Bug 859169

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.

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/

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.

(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.

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

(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

Making this bug depend on bug 1117751, this has to get fixed in RHEL 7 first to not introduce regressions.

Since it seems this won't be fixed for 7.1 in RHEL 7, I'm moving this bug to 6.8.

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