SIGPIPE is fatal if not handled or ignored and it can
come at any time during the TCP session. Which means
that none of the solutions suggested by others in the
list will work.
And it is wrong to rely on OpenSSL for solving a TCP
closure at the remote end which is essentially a TCP
issue.
write() or read() will return a 0 or -1 on a closed
socket, so you stand to lose nothing by ignoring
SIGPIPE.
regards,
Girish
--- Kyle Hamilton <[EMAIL PROTECTED]> wrote:
> 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]
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
