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'

# 连接到远程主机 foobar
telnet = 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