我写socket相关的程序也不是一天两天了,在我的记忆中,只要处理好recv(或read)的返回值中<0,==0,>0三种情况,程序便不会有什么问题.但最近在看公司的源代码时,发现代码中直接将SIGPIPE设置为SIG_IGN.而且附上一段注释:往一个已经关闭的socket写入数据会触发SIGPIPE.我心中顿时一惊,我以前从来没这样做过,虽然没出问题,难道只是我运气好? 周末,决定验证一下. 首先,socket的读事件中,返回0表示socket已关闭.如果已经关闭,再往里面写东西肯定会出问题

起因 同事想要写一个代码,主进程中监听SIGINT.SIGTERM信号退出,并关闭启动的子进程,代码类似这样 import signal import sys import time from multiprocessing import Process from multiprocessing import Manager class Test: def __init__(self): self.is_running = True if sys.platform != 'win32': sig

在调试cs时,s端循环收,c端循环发,s端意外崩溃后,c端自动退出,终端提示SIGPIPE导致c端退出.man 7 signal: SIGPIPE Term Broken pipe: write to pipe with no readers SIGPIPE发生在:写一个没有读的管道,默认动作是终止程序.man 2 write: EPIPE fd is connected to a pipe or socket whose reading end is closed. When this hap

进程间的通讯 进程间为什么需要通讯? 共享数据.数据传输.消息通知.进程控制 进程间的通讯有哪些类型? 首先,联系前面讲过的知识,进程之间的用户地址空间是相互独立的,不能进行互相访问,但是,内核空间却是共享的,所以进程间的通信要通过内核. 这里以Linux为例,介绍几种常见的Linux进程间的通讯方式:共享内存.管道.消息队列.信号量.信号. 管道 如果你学习过linux命令肯定见过 | 这个竖线. $ ps auxf | grep mysql 上面命令里的竖线 | 就是一个管道,它在这里的作用

GDB调试网络程序时,会遇到SIGPIPE信息,默认GDB会把程序停下来,即使程序使用signal(SIGPIPE, SIG_IGN);来忽略信号.用handle命令设置一下缺省的signal的处理行为即可:(在gdb模式下运行下面的命令)     handle SIGPIPE nostop print如果连信息提示都不想看见,可以这样设置:    handle SIGPIPE nostop noprint

转自:http://blog.csdn.net/lmh12506/article/details/8457772 前一段面试的时候被问到项目中有没有处理SIGPIPE信号,怎么处理的?当时没有答出来,今天终于找到答案了,记录一下. SIGPIPE信号详解 当服务器close一个连接时,若client端接着发数据.根据TCP协议的规定,会收到一个RST响应,client再往这个服务器发送数据时,系统会发出一个SIGPIPE信号给进程,告诉进程这个连接已经断开了,不要再写了. 我写了一个服务器程序,

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

我写了一个服务器程序,在Linux下测试,然后用C++写了客户端用千万级别数量的短链接进行压力测试.  但是服务器总是莫名退出,没有core文件. 最后问题确定为, 对一个对端已经关闭的socket调用两次write, 第二次将会生成SIGPIPE信号, 该信号默认结束进程. 具体的分析可以结合TCP的"四次握手"关闭. TCP是全双工的信道, 可以看作两条单工信道, TCP连接两端的两个端点各负责一条. 当对端调用close时, 虽然本意是关闭整个两条信道, 但本端只是收到FIN包.

当服务器close一个连接时,若client端接着发数据.根据TCP协议的规定,会收到一个RST响应,client再往这个服务器发送数据时,系统会发出一个SIGPIPE信号给进程,告诉进程这个连接已经断开了,不要再写了. Linux下测试,然后用C++写了客户端用千万级别数量的短链接进行压力测试.  但是服务器总是莫名退出,没有core文件. signal(SIGPIPE, SIG_IGN); 我的程序产生这个信号的原因是:  client端通过 pipe 发送信息到server端后,就关闭cl

主要内容:Socket的异步通知机制. 内核版本:3.15.2 我的博客:http://blog.csdn.net/zhangskd 概述 socket上定义了几个IO事件:状态改变事件.有数据可读事件.有发送缓存可写事件.有IO错误事件. 对于这些事件,socket中分别定义了相应的事件处理函数,也称回调函数. Socket I/O事件的处理过程中,要使用到sock上的两个队列:等待队列和异步通知队列,这两个队列中 都保存着等待该Socket I/O事件的进程. Q:为什么要使用两个队列,等待

.note-content { font-family: "Helvetica Neue", Arial, "Hiragino Sans GB", STHeiti, "Microsoft YaHei", "WenQuanYi Micro Hei", SimSun, Song, sans-serif } 本文转载自春哥也编程.我对排版做了整理,使更方便浏览. SIGQUIT 建立CORE文件终止进程,并且生成core文件SIGI

http://blog.csdn.net/xgjianstart/article/details/4544418 通过命令 kill -l  可查看全部信号 SIGHUP 终止进程 终端线路挂断 本信号在用户终端连接(正常或非正常)结束时发出,通常是在终端的控制进程结束时, 通知同一session内的各个作业, 这时它们与控制终端不再关联.  SIGINT 终止进程 中断进程 程序终止(interrupt)信号, 在用户键入INTR字符(通常是Ctrl-C)时发出  SIGQUIT 建立CORE

文章来源:http://blog.163.com/niuxiangshan@126/blog/static/170596595201221942952676/   当服务器close一个连接时,若client端接着发数据.根据TCP 协议的规定,会收到一个RST响应,client再往这个服务器发送数据时,系统会发出一个SIGPIPE信号给进程,告诉进程这个连接已经断开了,不要再写了.  根据信号的默认处理规则SIGPIPE信号的默认执行动作是terminate(终止.退出),所以client会退

http://www.cppblog.com/elva/archive/2008/09/10/61544.html 收集一些网上的资料,以便参考: http://blog.chinaunix.net/u2/69143/showart_1087349.html 当服务器close一个连接时,若client端接着发数据.根据TCP协议的规定,会收到一个RST响应,client再往这个服务器发送数据时,系统会发出一个SIGPIPE信号给进程,告诉进程这个连接已经断开了,不要再写了.    根据信号的默

1.用途说明 trap是一个shell内建命令,它用来在脚本中指定信号如何处理.比如,按Ctrl+C会使脚本终止执行,实际上系统发送了SIGINT信号给脚本进程,SIGINT信号的默认处理方式就是退出程序.如果要在Ctrl+C不退出程序,那么就得使用trap命令来指定一下SIGINT的处理方式了.trap命令不仅仅处理Linux信号,还能对脚本退出(EXIT).调试(DEBUG).错误(ERR).返回(RETURN)等情况指定处理方式. 2.常用参数 trap [-lp] [[arg] sigs

PS: 如果服务器程序不忽略SIGPIPE,在某些时候TCP writer收到这个信号,会导致进程退出 The rule that applies is: When a process writes to a socket that has received an RST, the SIGPIPE signal is sent to the process. The default action of this signal is to terminate the process, so the

SIGQUIT    建立CORE文件终止进程,并且生成core文件SIGILL     建立CORE文件       非法指令SIGTRAP    建立CORE文件       跟踪自陷SIGBUS     建立CORE文件       总线错误SIGSEGV    建立CORE文件        段非法错误SIGFPE     建立CORE文件       浮点异常SIGIOT     建立CORE文件        执行I/O自陷 SIGSTOP    停止进程     非终端来的停止信号

 信号 信号是由用户.系统或者进程发送给目标进程的信息.以通知目标进程某个状态的改变或系统异常. Linux信号可由例如以下条件产生: 对于前台进程.用户能够通过输入特殊的终端字符来给它发送信号.比方输入Ctrl+C一般会给进程发送一个终端信号. 2.系统异常 系统状态变化 执行kill命令或调用kill函数 Linux信号概述 发送信号 Linux下,一个进程给其它进程发送信号的API是kill函数.其定义例如以下: #include <sys/types.h> #include <

PHP信号管理   SIGHUP     终止进程     终端线路挂断 SIGINT     终止进程     中断进程 SIGQUIT    建立CORE文件终止进程,并且生成core文件 SIGILL   建立CORE文件       非法指令 SIGTRAP    建立CORE文件       跟踪自陷 SIGBUS   建立CORE文件       总线错误 SIGSEGV   建立CORE文件        段非法错误 SIGFPE   建立CORE文件       浮点异常 SIG

trap命令用于指定在接收到信号后将要采取的动作.常见的用途是在脚本程序被中断时完成清理工作.不过,这次我遇到它,是因为客户有个需求:从终端访问服务器的用户,其登陆服务器后会自动运行某个命令,例如打开应用(命令写在.bashrc等文件中),最后退出,并断开连接:期间是不能允许其使用Ctrl+C等中断退出应用,而回到Shell环境,否则可能会带来安全问题.当然,解决的方式有很多,如在应用中屏蔽中断信号.使用chroot方式访问等.但这些方法都有一些限制,如需要修改应用,让telnet等支持chro

Linux信号(signal) 机制分析 [摘要]本文分析了Linux内核对于信号的实现机制和应用层的相关处理.首先介绍了软中断信号的本质及信号的两种不同分类方法尤其是不可靠信号的原理.接着分析了内核对于信号的处理流程包括信号的触发/注册/执行及注销等.最后介绍了应用层的相关处理,主要包括信号处理函数的安装.信号的发送.屏蔽阻塞等,最后给了几个简单的应用实例. [关键字]软中断信号,signal,sigaction,kill,sigqueue,settimer,sigmask,sigprocma