How to prevent SIGPIPEs or handle them properly

Question

I have a small server program that accepts connections on a TCP or local UNIX socket  reads a simple command and  depending on the command  sends a reply  The problem is that the client may have no interest in the answer and sometimes exits early   So writing to that socket will cause a SIGPIPE and make my server crash  What s the best practice to prevent the crash here  Is there a way to check if the other side of the line is still reading   select   doesn t seem to work here as it always says the socket is writable   Or should I just catch the SIGPIPE with a handler and ignore it

User · Answer

Another method is to change the socket so it never generates SIGPIPE on write(). This is more convenient in libraries, where you might not want a global signal handler for SIGPIPE.

On most BSD-based (MacOS, FreeBSD...) systems, (assuming you are using C/C++), you can do this with:

int set = 1;
setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int));

With this in effect, instead of the SIGPIPE signal being generated, EPIPE will be returned.

User · Answer

Or should I just catch the SIGPIPE with a handler and ignore it    I believe that is right on   You want to know when the other end has closed their descriptor and that s what SIGPIPE tells you   Sam

User · Answer

Under a modern POSIX system  i e  Linux   you can use the sigprocmask   function    include  lt signal h gt   void block signal int signal to block    i e  SIGPIPE            sigset t set      sigset t old state          get the current state            sigprocmask SIG BLOCK  NULL   amp old state           add signal to block to that existing state            set   old state      sigaddset  amp set  signal to block           block that signal also            sigprocmask SIG BLOCK   amp set  NULL               deal with old state if required         If you want to restore the previous state later  make sure to save the old state somewhere safe  If you call that function multiple times  you need to either use a stack or only save the first or last old state    or maybe have a function which removes a specific blocked signal   For more info read the man page

User · Answer

I m super late to the party  but SO NOSIGPIPE isn t portable  and might not work on your system  it seems to be a BSD thing    A nice alternative if you re on  say  a Linux system without SO NOSIGPIPE would be to set the MSG NOSIGNAL flag on your send 2  call    Example replacing write      by send     MSG NOSIGNAL   see nobar s comment   char buf 888     write  sockfd  buf  sizeof buf     send     sockfd  buf  sizeof buf   MSG NOSIGNAL

User · Answer

In this post I described possible solution for Solaris case when neither SO NOSIGPIPE nor MSG NOSIGNAL is available      Instead  we have to temporarily suppress SIGPIPE in the current thread that executes library code   Here s how to do this  to suppress SIGPIPE we first check if it is pending   If it does  this means that it is blocked in this thread  and we have to do nothing   If the library generates additional SIGPIPE  it will be merged with the pending one  and that s a no-op   If SIGPIPE is not pending then we block it in this thread  and also check whether it was already blocked   Then we are free to execute our writes   When we are to restore SIGPIPE to its original state  we do the following  if SIGPIPE was pending originally  we do nothing   Otherwise we check if it is pending now   If it does  which means that out actions have generated one or more SIGPIPEs   then we wait for it in this thread  thus clearing its pending status  to do this we use sigtimedwait   with zero timeout  this is to avoid blocking in a scenario where malicious user sent SIGPIPE manually to a whole process  in this case we will see it pending  but other thread may handle it before we had a change to wait for it    After clearing pending status we unblock SIGPIPE in this thread  but only if it wasn t blocked originally    Example code at https   github com kroki XProbes blob 1447f3d93b6dbf273919af15e59f35cca58fcc23 src libxprobes c L156

User · Answer

Another method is to change the socket so it never generates SIGPIPE on write(). This is more convenient in libraries, where you might not want a global signal handler for SIGPIPE.

On most BSD-based (MacOS, FreeBSD...) systems, (assuming you are using C/C++), you can do this with:

int set = 1;
setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int));

With this in effect, instead of the SIGPIPE signal being generated, EPIPE will be returned.

User · Answer

You generally want to ignore the SIGPIPE and handle the error directly in your code   This is because signal handlers in C have many restrictions on what they can do   The most portable way to do this is to set the SIGPIPE handler to SIG IGN   This will prevent any socket or pipe write from causing a SIGPIPE signal   To ignore the SIGPIPE signal  use the following code   signal SIGPIPE  SIG IGN     If you re using the send   call  another option is to use the MSG NOSIGNAL option  which will turn the SIGPIPE behavior off on a per call basis   Note that not all operating systems support the MSG NOSIGNAL flag   Lastly  you may also want to consider the SO SIGNOPIPE socket flag that can be set with setsockopt   on some operating systems   This will prevent SIGPIPE from being caused by writes just to the sockets it is set on

User · Answer

Linux manual said      EPIPE  The local end has been shut down on a connection oriented                 socket   In this case the process will also receive a SIGPIPE                 unless MSG NOSIGNAL is set    But for Ubuntu 12 04 it isn t right  I wrote a test for that case and I always receive EPIPE withot SIGPIPE  SIGPIPE is genereated if I try to write to the same broken socket second time  So you don t need to ignore SIGPIPE if this signal happens it means logic error in your program

User · Answer

You cannot prevent the process on the far end of a pipe from exiting  and if it exits before you ve finished writing  you will get a SIGPIPE signal   If you SIG IGN the signal  then your write will return with an error - and you need to note and react to that error   Just catching and ignoring the signal in a handler is not a good idea -- you must note that the pipe is now defunct and modify the program s behaviour so it does not write to the pipe again  because the signal will be generated again  and ignored again  and you ll try again  and the whole process could go on for a long time and waste a lot of CPU power

User · Answer

Handle SIGPIPE Locally  It s usually best to handle the error locally rather than in a global signal event handler since locally you will have more context as to what s going on and what recourse to take   I have a communication layer in one of my apps that allows my app to communicate with an external accessory   When a write error occurs I throw and exception in the communication layer and let it bubble up to a try catch block to handle it there   Code   The code to ignore a SIGPIPE signal so that you can handle it locally is      We expect write failures to occur but we want to handle them where     the error occurs rather than in a SIGPIPE handler  signal SIGPIPE  SIG IGN     This code will prevent the SIGPIPE signal from being raised  but you will get a read   write error when trying to use the socket  so you will need to check for that

User · Answer

What s the best practice to prevent the crash here     Either disable sigpipes as per everybody  or catch and ignore the error      Is there a way to check if the other side of the line is still reading     Yes  use select        select   doesn t seem to work here as it always says the socket is writable    You need to select on the read bits  You can probably ignore the write bits   When the far end closes its file handle  select will tell you that there is data ready to read  When you go and read that  you will get back 0 bytes  which is how the OS tells you that the file handle has been closed   The only time you can t ignore the write bits is if you are sending large volumes  and there is a risk of the other end getting backlogged  which can cause your buffers to fill  If that happens  then trying to write to the file handle can cause your program thread to block or fail  Testing select before writing will protect you from that  but it doesn t guarantee that the other end is healthy or that your data is going to arrive   Note that you can get a sigpipe from close    as well as when you write   Close flushes any buffered data  If the other end has already been closed  then close will fail  and you will receive a sigpipe    If you are using buffered TCPIP  then a successful write just means your data has been queued to send  it doesn t mean it has been sent  Until you successfully call close  you don t know that your data has been sent   Sigpipe tells you something has gone wrong  it doesn t tell you what  or what you should do about it

[c] How to prevent SIGPIPEs (or handle them properly)

Examples related to c

Examples related to io

Examples related to signals

Examples related to broken-pipe

Examples related to sigpipe