None of the solutions suggested by others in the list
will protect you against a SIGPIPE for the simple
reason that it is a fatal signal if not handled or
ignored and it can come at any time during the TCP
session...
Ignoring SIGPIPE is one of the steps in writing a
server daemon and it is standard practice.
Best,
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]
