首页 > 代码库 > linux 信号量 二

linux 信号量 二

今天碰到一个SIGHUP问题,再复习一遍:

    有些信号的默认处理方式为“终止+core”,这里的core表示,进程终止时,会在进程的当前工作目录生产一个core文件,该文件是进程终止时的内存快照,以便以后供debugger调试用。

    以下情况不会生产core文件:

       (1)为程序设置了set-user-ID并且用户不是程序的所有者;

       (2)为程序设置了set-group-ID并且用户不是程序的组所有者;

       (3)进程在当前工作目录下面没有写权限;

       (4)当前工作目录下已有core文件且进程对该core文件没有写权限;

       (5)core文件过大。

各种信号产生条件和默认处理方式描述如下:

SIGABRT     默认处理方式:终止+core;当程序调用abort函数时,会产生该信号。程序异常终止。

SIGALRM     默认处理方式:终止;当由alarm或setitimer函数设置的定时器超时时,会产生该信号。

SIGBUS     默认处理方式:终止+core;经常因为内存错误产生该信号。

SIGCHLD     默认处理方式:忽略;当进程terminate或stopped的时候,该信号会发送给父进程。如果父进程需要知道子进程什么时候终止,父进程必须捕获该信号。通常在该信号的捕获函数中调用wait或waitpid获取子进程的pid和终止状态。

SIGCONT     默认处理方式:忽略/继续;作业控制命令进程继续执行时,该信号发送给进程。如果进程之前已被停止,则该信号的默认处理方式是继续进程的执行;否则,忽略该信号。

SIGFPE     默认处理方式:终止+core;当发生算术错误(如:除零,溢出等)时,产生该信号。

SIGHUP     默认处理方式:终止;当终端界面检测到连接断开时,内核向与控制终端的session leader进程发送该信号(当且仅当终端的CLOCAL标识位没有被设置时,才会发送该信号)。接收信号的session leader可能是后台进程,这与普通终端产生的信号不同,普通终端信号接收者是前台进程组。另外,当控制终端的session leader终止时,SIGHUP信号会发送到前台进程组。因为守护进程没有控制终端,通常不应该接收该信号的,所以这个信号常常被用作守护进程重新读取配置文件的信号。                 

SIGILL     默认处理方式:终止;当处理器执行了非法指令时,产生该信号。

SIGINT     默认处理方式:终止;当向终端输入终端键(Control+C或DELETE)时,终端产生SIGINT信号。该信号被发送到前台进程组。通常用来终止已运行的进程。

SIGIO     默认处理方式:终止/忽略;该信号用来提供异步IO模式。当有IO可用时,产生该信号通知进程。

SIGKILL     默认处理方式:终止;该信号给超级用户提供了终止任何进程的能力,通常通过kill函数或命令。该信号不能够被忽略或捕获。

SIGPIPE     默认处理方式:终止;当向已经关闭读者的管道写数据时,会产生该信号。同样向未连接的SOCK_STREAM类型的socket写数据时,也会产生该信号。

SIGPOLL     默认处理方式:终止;当指定的事件发生在可选择的设备上时,产生该信号。

SIGPROF     默认处理方式:终止;由setitimer设置的间隔定时器超时会产生该信号。

SIGPWR     默认处理方式:终止;当系统有UPS(Uninterruptible Power Supply,即电池)时,断电后使用电池,当电池电量低时,会产生该信号通知进程在1530秒内关闭。

SIGQUIT     默认处理方式:终止+core;当输入退出键(Control+\)时,终端将会产生SIGQUIT信号,该信号被传送到前台进程组。

SIGSEGV     默认处理方式:终止+core;非法内存引用时,产生该信号。

SIGSTOP     默认处理方式:停止进程;作业控制信号,用来停止进程。该信号不能被忽略或捕获。

SIGSYS     默认处理方式:终止+core;非法系统调用时,产生该信号。

SIGTERM     默认处理方式:终止;kill函数默认发送的信号,用来终止进程。

SIGTRAP     默认处理方式:终止+core;系统定义的硬件错误。通常,在遇到调试断点时,将控制权传递给debugger。

SIGTSTP     默认处理方式:停止进程;当输入挂起键(Control+Z)时,终端产生该(交互式停止)信号停止进程。该信号被发送给前台进程组。

SIGTTIN     默认处理方式:停止进程;当后台进程组中的进程要求从控制终端读取数据时,会产生该信号。有两个例外情况:1、要求读数据的后台进程忽略或阻塞了该信号,2、进程所属进程组是“孤儿”。在这两种情况下,不会产生该信号,否则,read会错误返回,并将errno设置为EIO。

SIGTTOU     默认处理方式:停止进程;当后台进程组中的进程要求写数据到控制终端时,会产生该信号。后台进程可以被允许写数据到控制终端。当不允许后台进程写数据到控制终端时,write会错误返回,并将errno设置为EIO。到有两个例外情况:1、要求写数据的后台进程忽略或阻塞了该信号,2、进程所属进程组是“孤儿”。在这两种情况下,不会产生该信号。

SIGURG     默认处理方式:忽略;当网络连接(Socket)接收到带外数据(out-of-band data)时,会产生该信号。

SIGUSR1     默认处理方式:终止;用户自定义的信号。

SIGUSR2     默认处理方式:终止;用户自定义的信号。

SIGVTALRM     默认处理方式:终止;由setitimer设置的虚拟定时器超时时,产生该信号。

SIGXCPU     默认处理方式:终止+core/忽略;进程超过了CPU的软限制时,产生该信号。

SIGXFSZ     默认处理方式:终止+core/忽略;进程超过了文件大小的软限制时,产生该信号。

 

原因,有人用ruby的telnet模块整了个windows端的自动测试,脚本没执行完就logout了导致有些程序
总莫名奇妙死掉; 可是并不是所有调用都出题,好像只有最后一个调用除了问题,而且telnet.cmd("script")
应该是阻塞型的啊,怎么脚本没执行完logout就执行了,太TMD奇怪了; 可能是脚本有问题吧,下周
检查一下脚本代码。
require ‘net/telnet‘ # 连接到远程主机 foobartelnet = Net::Telnet.new("Host" => "foobar") {|c| print c} # 登陆telnet.login("your name", "your password") {|c| print c}# 登陆后等待提示 telnet.cmd("ls") {|c| print c}# 执行命令后等待提示 # 稍复杂的例子telnet.cmd("sleep 5 && echo foobar &") {|c| print c} STDOUT.flush # <- 若没有这句的话,是很难看出程序已经运行到这里的 # 等待前面命令的输出telnet.waitfor(/foobar\Z/) {|c| print c} # 结束登陆会话telnet.cmd("exit") {|c| print c}telnet.close
 
 
 

linux 信号量 二