SIGPIPE is a remnant of BSD attempting to overlay UNIX socket (named
pipe) semantics onto TCP/IP connections. If the socket that you are
writing to is a socket (or pipe), AND the pipe is closed, then you
receive a SIGPIPE.
In this case, the 'good reason' for it is that what you think is
supposed to be listening isn't listening anymore, so you may need to
update your internal state. However, since the other effect of
writing to a socket that is remote-closed is the descriptor itself
being closed, there's no reason to worry about it.
I help maintain a MUD software (that uses OpenSSL); often players will
disconnect by closing their clients instead of using the QUIT command,
and this leads to attempts to send information to them. When the
software receives the TCP RST ('connection reset by peer'), it also
receives a SIGPIPE. However, we have no need to deal with it, since
we check the return status of the write operation; if it fails, we
close the socket and clean up the memory allocated to that connection.
On 2/12/06, Alberto Alonso <[EMAIL PROTECTED]> wrote:
> I personally don't know why pipes are even in use in the openssl
> internals (though I bet there is a good reason for it :-)
It's there because the underlying operating system forces them to be
there. It's certainly not at the behest of the OpenSSL team.
> Ignoring SIGPIPE (or most signals for that matter) is not really
> that good. They get generated for good reasons.
...explained above...
> In my case, depending on what came down the wire, I have to interact
> with other utilities in the system, therefore opening pipes. I need
> to make sure I get the signals when a system tool exits unexpectedly.
Alright, then just check to see what descriptor actually caused the
SIGPIPE (instead of setting it to SIG_IGN, you always have the ability
to write your own handler). If it's a descriptor that connects to
another utility, handle that special case (preferably by setting a
global variable and exiting the signal handler quickly, before
handling the exceptional circumstance in your main program loop --
this is akin to a 'deferred procedure call' in Windows 2000+ device
driver programming). If it's not, then it probably belongs to a
TLS/SSL connection, and can be safely ignored (since you're supposed
to be checking the return statuses of all of your OpenSSL calls
anyway, and since you're trying to shut down the SSL socket, you might
as well just call SSL_free() immediately after the SSL_shutdown
[taking into account the possibility of an SSL_WANTS_WRITE return
status].
-Kyle H
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
