【整理】服务器忽略SIGPIPE信号原因及方法

1.原因

对一个对端已经关闭的socket调用两次write，第二次将会生成SIGPIPE信号, 该信号默认结束进程。

具体的分析可以结合TCP关闭的”四次握手”。TCP是全双工的信道, 可以看作两条单工信道， TCP连接两端的两个端点各负责一条。当对端调用close时， 虽然本意是关闭整个两条信道，但本端只是收到FIN包。 按照TCP协议的语义， 表示对端只是关闭了其所负责的那一条单工信道， 仍然可以继续接收数据。 也就是说， 因为TCP协议的限制， 一个端点无法获知对端的socket是调用了close还是shutdown。

对一个已经收到FIN包的socket调用read方法， 如果接收缓冲已空， 则返回0， 这就是常说的表示连接关闭。但第一次对其调用write方法时，如果发送缓冲没问题，会返回正确写入(发送)。但发送的报文会导致对端发送RST报文，因为对端的socket已经调用了close，完全关闭，既不发送，也不接收数据。所以，第二次调用write方法(假设在收到RST之后)， 会生成SIGPIPE信号，导致进程退出。

在linux下写socket的程序的时候，如果尝试send到一个disconnected socket上，就会让底层抛出一个SIGPIPE信号。
这个信号的缺省处理方法是退出进程，大多数时候这都不是我们期望的。

2.方法

为了避免进程退出, 可以捕获SIGPIPE信号，或者忽略它，方法有：

（1）间接忽略

static void SignalHandler(int nSigno)  
{  
    signal(nSigno, SignalHandler);  
    switch(nSigno)  
    {  
    case SIGPIPE:  
        printf("Process will not exit\n");  
        break;  
    default:  
        printf("%d signal unregister\n", nSigno);  
        break;  
    }  
}  

atic void InitSignalHandler()  
{  
    signal(SIGPIPE , &SignalHandler);  
}  

int main（）  
{  
        InitSignalHandler();  
           ........  
         return 0；  
}  

（2）直接忽略

signal(SIGPIPE,SIG_IGN);  

（3）重载signaction

struct sigaction sa;  
sa.sa_handler = SIG_IGN;  
sigaction( SIGPIPE, &sa, 0 );  

3.其他

正常情况下，（1）（2）（3）都是可以的。

如果（1）（2）（3）收到SIGPIPE之后依然进程退出，可能的一个原因如下：

查询SIGPIPE这个信号的特性：

如果在写到管道时读进程已终止，则产生此信号。当类型为SOCK_STREAM的套接字已不再连接时，进程写到该套接字也产生此信号。 ——《UNIX环境高级编程》中10.2节

客户端是用send（）进行发送数据的，通过man手册查看send（）函数，看到有一条这样说：

  MSG_NOSIGNAL
          Requests not to send SIGPIPE on errors on stream oriented sockets when the other end breaks the connection. The EPIPE error is still returned.

于是将send（）最后一个参数flags改为MSG_NOSIGNAL，再次启动客户端测试。SIGPIPE成功被忽略，客户端没有因为该信号退出。

【参考：http://blog.sina.com.cn/s/blog_502d765f0100kopn.html
http://blog.csdn.net/woxiaozhi/article/details/40624033】