linux socket编程 出现信号SIGPIPE,分析及解决
2017-06-12 18:15
316 查看
在编写一个仿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里面写。
摘自:
当服务器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到一个disconnectedsocket上,就会让底层抛出一个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,则表明该服务器主机在我们指定的端口上没有进程在等待与之连接(例如服务器进程也许没有启动),这称为硬错(harderror),客户一接收到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 , [b]write函数的返回值,就不知道服务器是否响应了RST,此时客户端如果向接收了RST的套接口进行写操作时,内核给该进程发一个SIGPIPE信号。此信号的缺省行为就是终止进程,所以,进程必须捕获它以免不情愿地被终止。
[/b]
进程不论是捕获了该信号并从其信号处理程序返回,还是不理会该信号,写操作都返回EPIPE错误。
3. 服务器主机崩溃后重启
如果服务器主机与客户端建立连接后崩溃,如果此时,客户端向服务器发送数据,而服务器已经崩溃不能响应客户端ACK,客户TCP将持续重传数据分节,试图从服务器上接收一个ACK,如果服务器一直崩溃客户端会发现服务器已经崩溃或目的地不可达,但可能需要比较长的时间;如果服务器在客户端发现崩溃前重启,服务器的TCP丢失了崩溃前的所有连接信息,所以服务器TCP对接收的客户数据分节以RST响应。
二、关于socket的recv:
对于TCP non-blocking
socket,recv返回值== -1,但是errno == EAGAIN, 此时表示在执行recv时相应的socketbuffer中没有数据,应该继续recv。
【If no messages are available atthe
socket andO_NONBLOCK is not set on the
socket's filedescriptor, recv() shall block until a message arrives. Ifno messages are available at the
socket andO_NONBLOCK is set on the
socket's filedescriptor,
recv() shall fail and set errno to[EAGAIN] or [EWOULDBLOCK].】
对于UDPrecv 应该一直读取直到recv()==-1 &&errno==EAGAIN,表示buffer中数据包被全部读取。
接收数据时常遇到Resourcetemporarilyunavailable的提示,errno代码为11(EAGAIN)。这表明你在非阻塞模式下调用了阻塞操作,在该操作没有完成就返回这个错误,这个错误不会破坏socket的同步,不用管它,下次循环接着recv就可以。对非阻塞socket而言,EAGAIN不是一种错误。在VxWorks和Windows上,EAGAIN的名字叫做EWOULDBLOCK。其实这算不上错误,只是一种异常而已。
外记:
accetp()是慢系统调用,在信号产生时会中断其调用并将errno变量设置为EINTR,此时应重新调用accept()。
所以使用时应这样:
signal 与 sigaction 区别:
signal函数每次设置具体的信号处理函数(非SIG_IGN)只能生效一次,每次在进程响应处理信号时,随即将信号处理函数恢复为默认处理方式.所以如果想多次相同方式处理某个信号,通常的做法是,在响应函数开始,再次调用signal设置。
这种代码段的一个问题是:在信号发生之后到信号处理程序中调用s i g na l函数之间有一个
时间窗口。在此段时间中,可能发生另一次中断信号。第二个信号会造成执行默认动作,而对
中断信号则是终止该进程。这种类型的程序段在大多数情况下会正常工作,使得我们认为它们
正确,而实际上却并不是如此。
另一个问题是:在进程不希望某种信号发生时,它不能关闭该信号
sigaction:
1.在信号处理程序被调用时,系统建立的新信号屏蔽字会自动包括正被递送的信号。因此保证了在处理一个
给定的信号时,如果这种信号再次发生,那么它会被阻塞到对前一个信号的处理结束为止
2.响应函数设置后就一直有效,不会重置
3.对除S I G A L R M以外的所有信号都企图设置S A _ R E S TA RT标志,于是被这些信号中断
的系统调用(read,write)都能自动再起动。不希望再起动由SI 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)brokenpipe的字面意思是“管道破裂”。broken pipe的原因是该管道的读端被关闭。
2)brokenpipe经常发生socket关闭之后(或者其他的描述符关闭之后)的write操作中
3)发生broken pipe错误时,进程收到SIGPIPE信号,默认动作是进程终止。
4)broken pipe最直接的意思是:写入端出现的时候,另一端却休息或退出了,
因此造成没有及时取走管道中的数据,从而系统异常退出;
服务器采用了fork的话,要收集垃圾进程,防止僵尸进程的产生,可以这样处理:
signal(SIGCHLD,SIG_IGN); 交给系统init去回收。
这里子进程就不会产生僵尸进程了。
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或者writesocket遭遇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到一个disconnectedsocket上,就会让底层抛出一个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,则表明该服务器主机在我们指定的端口上没有进程在等待与之连接(例如服务器进程也许没有启动),这称为硬错(harderror),客户一接收到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 , [b]write函数的返回值,就不知道服务器是否响应了RST,此时客户端如果向接收了RST的套接口进行写操作时,内核给该进程发一个SIGPIPE信号。此信号的缺省行为就是终止进程,所以,进程必须捕获它以免不情愿地被终止。
[/b]
进程不论是捕获了该信号并从其信号处理程序返回,还是不理会该信号,写操作都返回EPIPE错误。
3. 服务器主机崩溃后重启
如果服务器主机与客户端建立连接后崩溃,如果此时,客户端向服务器发送数据,而服务器已经崩溃不能响应客户端ACK,客户TCP将持续重传数据分节,试图从服务器上接收一个ACK,如果服务器一直崩溃客户端会发现服务器已经崩溃或目的地不可达,但可能需要比较长的时间;如果服务器在客户端发现崩溃前重启,服务器的TCP丢失了崩溃前的所有连接信息,所以服务器TCP对接收的客户数据分节以RST响应。
二、关于socket的recv:
对于TCP non-blocking
socket,recv返回值== -1,但是errno == EAGAIN, 此时表示在执行recv时相应的socketbuffer中没有数据,应该继续recv。
【If no messages are available atthe
socket andO_NONBLOCK is not set on the
socket's filedescriptor, recv() shall block until a message arrives. Ifno messages are available at the
socket andO_NONBLOCK is set on the
socket's filedescriptor,
recv() shall fail and set errno to[EAGAIN] or [EWOULDBLOCK].】
对于UDPrecv 应该一直读取直到recv()==-1 &&errno==EAGAIN,表示buffer中数据包被全部读取。
接收数据时常遇到Resourcetemporarilyunavailable的提示,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:%derrno EAGAIN\n",len); continue; } if (errno== EINTR) continue; perror("recverror\n"); break; } else if(len > 0){ printf("Recved:%s,and len is:%d \n",buff, len); len = send(sockfd,buff, len, 0); if (len <</span> 0) { perror("senderror"); return -1; } memset(buff,0, MAXBUF); continue; } else {//==0 printf("Disconnectedby peer!\n"); res = 0; return res; } } |
accetp()是慢系统调用,在信号产生时会中断其调用并将errno变量设置为EINTR,此时应重新调用accept()。
所以使用时应这样:
while(1){ if ( (connfd= accept(....))== -1) { if (errno== EINTR) continue; perror("accept()"); exit(1); } } |
signal函数每次设置具体的信号处理函数(非SIG_IGN)只能生效一次,每次在进程响应处理信号时,随即将信号处理函数恢复为默认处理方式.所以如果想多次相同方式处理某个信号,通常的做法是,在响应函数开始,再次调用signal设置。
int sig_int();//My signal handler ... signal(SIGINT,sig_int); ... int sig_int() {
signal(SIGINT,sig_int); .... }
这种代码段的一个问题是:在信号发生之后到信号处理程序中调用s i g na l函数之间有一个
时间窗口。在此段时间中,可能发生另一次中断信号。第二个信号会造成执行默认动作,而对
中断信号则是终止该进程。这种类型的程序段在大多数情况下会正常工作,使得我们认为它们
正确,而实际上却并不是如此。
另一个问题是:在进程不希望某种信号发生时,它不能关闭该信号
sigaction:
1.在信号处理程序被调用时,系统建立的新信号屏蔽字会自动包括正被递送的信号。因此保证了在处理一个
给定的信号时,如果这种信号再次发生,那么它会被阻塞到对前一个信号的处理结束为止
2.响应函数设置后就一直有效,不会重置
3.对除S I G A L R M以外的所有信号都企图设置S A _ R E S TA RT标志,于是被这些信号中断
的系统调用(read,write)都能自动再起动。不希望再起动由SI 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)brokenpipe的字面意思是“管道破裂”。broken pipe的原因是该管道的读端被关闭。
2)brokenpipe经常发生socket关闭之后(或者其他的描述符关闭之后)的write操作中
3)发生broken pipe错误时,进程收到SIGPIPE信号,默认动作是进程终止。
4)broken pipe最直接的意思是:写入端出现的时候,另一端却休息或退出了,
因此造成没有及时取走管道中的数据,从而系统异常退出;
服务器采用了fork的话,要收集垃圾进程,防止僵尸进程的产生,可以这样处理:
signal(SIGCHLD,SIG_IGN); 交给系统init去回收。
这里子进程就不会产生僵尸进程了。
相关文章推荐
- linux socket编程 出现信号SIGPIPE,分析及解决
- linux socket编程 出现信号SIGPIPE,分析及解决
- Linux网络编程socket错误分析
- 【Linux内核及驱动编程】Linux信号机制分析
- linux 网络编程 socket bind failed 问题解决
- Linux下 ntp 时间同步服务ntpd 出现 the NTP socket is in use, exiting 解决
- Linux网络编程socket错误分析
- Linux网络编程socket错误分析
- socket编程时SIGPIPE信号的处理
- crash分析vmcore和vmlinux出现不匹配问题的解决方法
- Linux网络编程socket错误分析
- 从“hello”开始去分析linux下的socket编程
- Linux网络编程socket错误分析
- 解决android socket编程出现的Caused by: android.os.NetworkOnMainThreadException错误
- Linux网络编程socket错误分析
- Linux编程之socket:tcp流协议产生的粘包问题及解决方法
- linux Socket数据发送中信号SIGPIPE及相关errno的研究
- Linux网络编程socket错误分析
- 【嵌入式Linux学习七步曲之第五篇 Linux内核及驱动编程】Linux信号机制分析
- linux下socket编程accept出现参数错误