Bug 470061 - Prevent SIGPIPE being raised when writing to closed socket
Prevent SIGPIPE being raised when writing to closed socket
Status: NEW
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Andrew Stitcher
Kim van der Riet
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-05 10:41 EST by Gordon Sim
Modified: 2013-02-24 09:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gordon Sim 2008-11-05 10:41:47 EST
On linux using MSG_NO_SIGNAL as a flag to send.
Comment 1 Andrew Stitcher 2010-04-26 23:11:21 EDT
For Posix platforms the current common qpid library code sets the signal status of the SIGPIPE signal to be ignored, so that disconnecting a socket from the remote end then writing to it doesn't cause a SIGPIPE which has a default handler which terminates the process.

For the broker this is completely ok.

However for the client library code this is not really a good plan, because we have no idea what the client code itself might be doing and ignoring SIGPIPE for the whole process might mess up something the application is trying to do.

There are no entirely portable solutions to this.
MSG_NOSIGNAL - some platforms support a flag for send() which stops the socket from raising the SIGPIPE signal on a send by send basis.
SO_NOSIGPIPE - Other platforms support a socket option which can be set on a socket to stop it generating SIGPIPE at all.

Linux supports MSG_NOSIGNAL 
FreeBSD both MSG_NOSIGNAL and SO_NOSIGPIPE
MacOS is documented to support SO_NOSIGPIPE on recent versions, but not documented to support MSG_NOSIGNAL
Solaris does not seem to support either!
Comment 2 Andrew Stitcher 2010-04-26 23:59:20 EDT
There appears to be another solution to this problem which is more portable - 

The SIGPIPE is supposed to only be sent to the thread that has performed the write()/send() that caused it so it should only need to be blocked in that thread itself. The write()/send() will return EPIPE if the signal would be sent and is blocked (or is ignored). So we could roughly speaking just block SIGPIPE around the send() calls themselves.

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