SIGPIPE信号

使用libevent编写websocket服务端时遇到了一个问题：

浏览器与服务端建立连接后，若刷新或关闭浏览器窗口（未监听相应事件并处理），服务端无法得知连接断开，按理说，这种情况属于client异常终止，跟拔网线的情况类似。这种情况下，服务端不知情，仍保留此连接，仍按照既定逻辑向client写数据，写了两次后，服务端程序终止（多次测试，均是第2次后终止），不是崩溃，是异常终止，非常不解。

 

问了一位很有经验的同事，得知是SIGPIPE信号导致程序终止。

查了相关资料，大致明白：连接建立，若某一端关闭连接，而另一端仍然向它写数据，第一次写数据后会收到RST响应，此后再写数据，内核将向进程发出SIGPIPE信号，通知进程此连接已经断开。而SIGPIPE信号的默认处理是终止程序，导致上述问题的发生。

 

为避免这种情况，可以选择忽略SIGPIPE信号，不执行任何动作。

#include <signal.h>
//SIGPIPE ignore
struct sigaction act;
act.sa_handler = SIG_IGN;
if (sigaction(SIGPIPE, &act, NULL) == 0) {
    LOG("SIGPIPE ignore");
}

From http://www.cnblogs.com/caosiyang/

 

最近为测试自己写的服务器，临时写了一个客户端，总是发现客户端收到SIGPIPE的信号，然后进程退出。

为了客户端进程收到SIGPIPE不退出，我打算忽略该信号，下面是我用过的方法：

（1）间接忽略

 

static void SignalHandler(int nSigno)
{
    signal(nSigno, SignalHandler);
    switch(nSigno)
    {
    case SIGPIPE:
        printf("Process will not exit
");
        break;
    default:
        printf("%d signal unregister
", 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 );

（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被忽略，客户端没有因为该信号退出。

将这次经历记录下来，与看到的人共享。

 当服务器close一个连接时，若client端接着发数据。根据TCP协议的规定，会收到一个RST响应，client再往这个服务器发送数据时，系统会发出一个SIGPIPE信号给进程，告诉进程这个连接已经断开了，不要再写了。
    根据信号的默认处理规则SIGPIPE信号的默认执行动作是terminate(终止、退出),所以client会退出。若不想客户端退出可以把SIGPIPE设为SIG_IGN

    如:    signal(SIGPIPE,SIG_IGN);
    这时SIGPIPE交给了系统处理。

  服务器采用了fork的话，要收集垃圾进程，防止僵尸进程的产生，可以这样处理：
  signal(SIGCHLD,SIG_IGN);　交给系统init去回收。
   这里子进程就不会产生僵尸进程了。

我写了一个服务器程序,在Linux下测试，然后用C++写了客户端用千万级别数量的短链接进行压力测试.  但是服务器总是莫名退出，没有core文件.

最后问题确定为, 对一个对端已经关闭的socket调用两次write, 第二次将会生成SIGPIPE信号, 该信号默认结束进程.

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

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

为了避免进程退出, 可以捕获SIGPIPE信号, 或者忽略它, 给它设置SIG_IGN信号处理函数:

signal(SIGPIPE, SIG_IGN);

这样, 第二次调用write方法时, 会返回-1, 同时errno置为SIGPIPE. 程序便能知道对端已经关闭.

 

在linux下写socket的程序的时候，如果尝试send到一个disconnected socket上，就会让底层抛出一个SIGPIPE信号。
这个信号的缺省处理方法是退出进程，大多数时候这都不是我们期望的。因此我们需要重载这个信号的处理方法。调用以下代码，即可安全的屏蔽SIGPIPE：

signal （SIGPIPE， SIG_IGN）；

我的程序产生这个信号的原因是: 
client端通过 pipe 发送信息到server端后，就关闭client端, 这时server端,返回信息给 client 端时就产生Broken pipe 信号了，服务器就会被系统结束了。

 

对于产生信号，我们可以在产生信号前利用方法 signal(int signum, sighandler_t handler) 设置信号的处理。如果没有调用此方法，系统就会调用默认处理方法：中止程序，显示提示信息(就是我们经常遇到的问题)。我们可以调用系统的处理方法，也可以自定义处理方法。 

系统里边定义了三种处理方法： 
(1)SIG_DFL信号专用的默认动作:
　　(a)如果默认动作是暂停线程，则该线程的执行被暂时挂起。当线程暂停期间，发送给线程的任何附加信号都不交付，直到该线程开始执行，但是SIGKILL除外。
　　(b)把挂起信号的信号动作设置成SIG_DFL，且其默认动作是忽略信号 (SIGCHLD)。
(2)SIG_IGN忽略信号
　　(a)该信号的交付对线程没有影响
　　(b)系统不允许把SIGKILL或SIGTOP信号的动作设置为SIG_DFL
3)SIG_ERR   

项目中我调用了signal(SIGPIPE, SIG_IGN), 这样产生  SIGPIPE 信号时就不会中止程序，直接把这个信号忽略掉。

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

在编写一个仿QQ软件，C/S模式。出现的问题：当客户机关闭时，服务器也随着关闭，纠结很久之后，我gdb了下，出现下面提示信息：

Program received signal SIGPIPE, Broken pipe.
0x0012e416 in __kernel_vsyscall ()

在 网上查了一下出现SIGPIPE的原因：如果尝试send到一个已关闭的 socket上两次，就会出现此信号，也就是用协议TCP的socket编程，服务器是不能知道客户机什么时候已经关闭了socket，导致还在向该已关 闭的socket上send，导致SIGPIPE。

而系统默认产生SIGPIPE信号的措施是关闭进程，所以出现了服务器也退出。

 

下面分析TCP协议的缺陷以至于服务器无法及时判断对方socket已关闭：

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

 

解决方法：

重新定义遇到SIGPIPE的措施，signal(SIGPIPE,   SIG_IGN);具体措施在函数SIG_IGN里面写。

 

摘自：

send或者write socket遭遇SIGPIPE信号

 

当服务器close一个连接时，若client端接着发数据。根据TCP协议的规定，会收到一个RST响应，client再往这个服务器发送数据时，系统会发出一个SIGPIPE信号给进程，告诉进程这个连接已经断开了，不要再写了。

又或者当一个进程向某个已经收到RST的socket执行写操作是，内核向该进程发送一个SIGPIPE信号。该信号的缺省学位是终止进程，因此进程必须捕获它以免不情愿的被终止。

根据信号的默认处理规则SIGPIPE信号的默认执行动作是terminate(终止、退出),所以client会退出。若不想客户端退出可以把 SIGPIPE设为SIG_IGN

如：signal(SIGPIPE, SIG_IGN);
这时SIGPIPE交给了系统处理。

服务器采用了fork的话，要收集垃圾进程，防止僵尸进程的产生，可以这样处理：
signal(SIGCHLD,SIG_IGN);
交给系统init去回收。
这里子进程就不会产生僵尸进程了。

在linux下写socket的程序的时候，如果尝试send到一个disconnected socket上，就会让底层抛出一个SIGPIPE信号。
这个信号的缺省处理方法是退出进程，大多数时候这都不是我们期望的。因此我们需要重载这个信号的处理方法。调用以下代码，即可安全的屏蔽SIGPIPE：
struct sigaction sa;
sa.sa_handler = SIG_IGN;
sigaction( SIGPIPE, &sa, 0 );

signal设置的信号句柄只能起一次作用，信号被捕获一次后，信号句柄就会被还原成默认值了。
sigaction设置的信号句柄，可以一直有效，值到你再次改变它的设置。

struct sigaction action;
action.sa_handler = handle_pipe;
sigemptyset(&action.sa_mask);
action.sa_flags = 0;
sigaction(SIGPIPE, &action, NULL);
void handle_pipe(int sig)
{
//不做任何处理即可
}

RST的含义为“复位”，它是TCP在某些错误情况下所发出的一种TCP分节。有三个条件可以产生RST:

1), SYN到达某端口但此端口上没有正在监听的服务器。
2), TCP想取消一个已有连接
3), TCP接收了一个根本不存在的连接上的分节。

1． Connect 函数返回错误ECONNREFUSED:
如果对客户的SYN的响应是RST，则表明该服务器主机在我们指定的端口上没有进程在等待与之连接（例如服务器进程也许没有启动），这称为硬错（hard error），客户一接收到RST，马上就返回错误ECONNREFUSED.

TCP为监听套接口维护两个队列。两个队列之和不超过listen函数第二个参数backlog。

当一个客户SYN到达时，若两个队列都是满的，TCP就忽略此分节，且不发送RST.这个因为：这种情况是暂时的，客户TCP将重发SYN，期望不久就能 在队列中找到空闲条目。要是TCP服务器发送了一个RST，客户connect函数将立即发送一个错误，强制应用进程处理这种情况，而不是让TCP正常的 重传机制来处理。还有，客户区别不了这两种情况：作为SYN的响应，意为“此端口上没有服务器”的RST和意为“有服务器在此端口上但其队列满”的 RST.
Posix.1g允许以下两种处理方法：忽略新的SYN，或为此SYN响应一个RST.历史上，所有源自Berkeley的实现都是忽略新的SYN。

2．如果杀掉服务器端处理客户端的子进程，进程退出后，关闭它打开的所有文件描述符，此时，当服务器TCP接收到来自此客户端的数据时，由于先前打开的那个套接字接口的进程已终止，所以以RST响应。

经常遇到的问题：
如果不判断read , write函数的返回值，就不知道服务器是否响应了RST, 此时客户端如果向接收了RST的套接口进行写操作时，内核给该进程发一个SIGPIPE信号。此信号的缺省行为就是终止进程，所以，进程必须捕获它以免不情愿地被终止。

进程不论是捕获了该信号并从其信号处理程序返回，还是不理会该信号，写操作都返回EPIPE错误。

3． 服务器主机崩溃后重启
如果服务器主机与客户端建立连接后崩溃，如果此时，客户端向服务器发送数据，而服务器已经崩溃不能响应客户端ACK，客户TCP将持续重传数据分节，试图从服务器上接收一个ACK，如果服务器一直崩溃客户端会发现服务器已经崩溃或目的地不可达，但可能需要比较长的时间； 如果服务器在客户端发现崩溃前重启，服务器的TCP丢失了崩溃前的所有连接信息，所以服务器TCP对接收的客户数据分节以RST响应。

二、关于socket的recv：

对于TCP non-blocking socket, recv返回值== -1，但是errno == EAGAIN, 此时表示在执行recv时相应的socket buffer中没有数据，应该继续recv。

【If no messages are available at the socket and O_NONBLOCK is not set on the socket's file descriptor, recv() shall block until a message arrives. If no messages are available at the socket and O_NONBLOCK is set on the socket's file descriptor, recv() shall fail and set errno to [EAGAIN] or [EWOULDBLOCK].】

对于UDP recv 应该一直读取直到recv（）==-1 && errno==EAGAIN，表示buffer中数据包被全部读取。

接收数据时常遇到Resource temporarily unavailable的提示，errno代码为11(EAGAIN)。这表明你在非阻塞模式下调用了阻塞操作，在该操作没有完成就返回这个错误，这个错误不会破坏socket的同步，不用管它，下次循环接着recv就可以。对非阻塞socket而言，EAGAIN不是一种错误。在VxWorks和 Windows上，EAGAIN的名字叫做EWOULDBLOCK。其实这算不上错误，只是一种异常而已。

 

 


while (res != 0)
{
//len = recv(sockfd, buff, MAXBUF, 0);


len = recv(sockfd, buff, 5, 0);
if (len <</span> 0 ) {
if(errno == EAGAIN) {
printf("RE-Len:%d errno EAGAIN ", len);
continue;

}

if (errno == EINTR)

continue;
perror("recv error ");
break;
} else if (len > 0) {
printf("Recved:%s, and len is:%d ", buff, len);
len = send(sockfd, buff, len, 0);
if (len <</span> 0) {
perror("send error");
return -1;
}
memset(buff, 0, MAXBUF);
continue;
} else { //==0

printf("Disconnected by peer! ");
res = 0;

return res;
}
}

外记：
accetp()是慢系统调用，在信号产生时会中断其调用并将errno变量设置为EINTR，此时应重新调用accept()。
所以使用时应这样：

while(1) {
if ( (connfd = accept(....)) == -1 ) {
if (errno == EINTR)
continue;
perror("accept()");
exit(1);
}



}

signal 与 sigaction 区别：
signal函数每次设置具体的信号处理函数(非SIG_IGN)只能生效一次,每次在进程响应处理信号时，随即将信号处理函数恢复为默认处理方式.所以如果想多次相同方式处理某个信号,通常的做法是,在响应函数开始,再次调用signal设置。

int sig_int(); //My signal handler

...
signal(SIGINT, sig_int);
...

int sig_int()
{


signal(SIGINT, sig_int);
....
}

这种代码段的一个问题是：在信号发生之后到信号处理程序中调用s i g n a l函数之间有一个
时间窗口。在此段时间中，可能发生另一次中断信号。第二个信号会造成执行默认动作，而对
中断信号则是终止该进程。这种类型的程序段在大多数情况下会正常工作，使得我们认为它们
正确，而实际上却并不是如此。
另一个问题是：在进程不希望某种信号发生时，它不能关闭该信号

sigaction:
1.在信号处理程序被调用时，系统建立的新信号屏蔽字会自动包括正被递送的信号。因此保证了在处理一个
给定的信号时，如果这种信号再次发生，那么它会被阻塞到对前一个信号的处理结束为止
2.响应函数设置后就一直有效,不会重置
3.对除S I G A L R M以外的所有信号都企图设置S A _ R E S TA RT标志，于是被这些信号中断
的系统调用(read,write)都能自动再起动。不希望再起动由S I G A L R M信号中断的系统调用的原因是希望对I / O操作可以设置时间限制。 所以希望能用相同方式处理信号的多次出现,最好用sigaction.信号只出现并处理一次,可以用signal

   服务端关闭已连接客户端，客户端接着发数据产生问题，

   1. 当服务器close一个连接时，若client端接着发数据。根据TCP协议的规定，会收到一个RST响应，client再往这个服务器发送数据时，系统会发出一个SIGPIPE信号给进程，告诉进程这个连接已经断开了，不要再写了。

    根据信号的默认处理规则SIGPIPE信号的默认执行动作是terminate(终止、退出),所以client会退出。若不想客户端退出可以把SIGPIPE设为SIG_IGN

    如:    signal(SIGPIPE,SIG_IGN);

这时SIGPIPE交给了系统处理。

 

   2. 客户端write一个已经被服务器端关闭的sock后，返回的错误信息Broken pipe.

     1）broken pipe的字面意思是“管道破裂”。broken pipe的原因是该管道的读端被关闭。

     2）broken pipe经常发生socket关闭之后（或者其他的描述符关闭之后）的write操作中

　　　3）发生broken pipe错误时，进程收到SIGPIPE信号，默认动作是进程终止。

     4）broken pipe最直接的意思是：写入端出现的时候，另一端却休息或退出了，

       因此造成没有及时取走管道中的数据，从而系统异常退出；

 

 

 

　　服务器采用了fork的话，要收集垃圾进程，防止僵尸进程的产生，可以这样处理：

          signal(SIGCHLD,SIG_IGN);　交给系统init去回收。

   这里子进程就不会产生僵尸进程了。