Bug 470061
| Summary: | Prevent SIGPIPE being raised when writing to closed socket | ||
|---|---|---|---|
| Product: | Red Hat Enterprise MRG | Reporter: | Gordon Sim <gsim> |
| Component: | qpid-cpp | Assignee: | Andrew Stitcher <astitcher> |
| Status: | CLOSED WONTFIX | QA Contact: | Kim van der Riet <kim.vdriet> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 1.0 | CC: | jross |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-05-22 14:35:04 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Gordon Sim
2008-11-05 15:41:47 UTC
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! 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. |