Linux信号

最新推荐文章于 2024-10-12 08:00:00 发布

jiangzhengdong

最新推荐文章于 2024-10-12 08:00:00 发布

阅读量885

点赞数

分类专栏： Linux 文章标签： Linux Signal

本文链接：https://blog.csdn.net/jiangzhengdong/article/details/9164895

版权

Linux 专栏收录该内容

37 篇文章 1 订阅

订阅专栏

通过$kill -l命令可以查看Linux中的信号及对应的整数。如下：

1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL
5) SIGTRAP      6) SIGABRT      7) SIGBUS       8) SIGFPE
9) SIGKILL     10) SIGUSR1     11) SIGSEGV     12) SIGUSR2
13) SIGPIPE     14) SIGALRM     15) SIGTERM     16) SIGSTKFLT 17) SIGCHLD
18) SIGCONT     19) SIGSTOP     20) SIGTSTP     21) SIGTTIN
22) SIGTTOU     23) SIGURG      24) SIGXCPU     25) SIGXFSZ
26) SIGVTALRM   27) SIGPROF     28) SIGWINCH    29) SIGIO
30) SIGPWR      31) SIGSYS      34) SIGRTMIN    35) SIGRTMIN+1
36) SIGRTMIN+2  37) SIGRTMIN+3  38) SIGRTMIN+4  39) SIGRTMIN+5
40) SIGRTMIN+6  41) SIGRTMIN+7  42) SIGRTMIN+8  43) SIGRTMIN+9
44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13
52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9
56) SIGRTMAX-8  57) SIGRTMAX-7  58) SIGRTMAX-6  59) SIGRTMAX-5
60) SIGRTMAX-4  61) SIGRTMAX-3  62) SIGRTMAX-2  63) SIGRTMAX-1
64) SIGRTMAX

其中，1 ~ 31的信号为传统UNIX支持的信号，是不可靠信号(非实时)，32 ~ 63的信号是后来扩充的，称做可靠信号(实时信号)。不可靠信号和可靠信号的区别在于前者不支持排队，可能会造成信号丢失，而后者则支持排队。

常见的信号

SIGHUP 1 和终端的连接断开，发送该信号给控制进程。通常用此信号来通知daemon重新读取配置文件（因为daemon不会有控制终端，通常不会收到该信号）。 SIGINT 2 用户中断（Ctrl + C）。

SIGABRT 6 调用abort函数产生（通常是自杀）。

SIGKILL 9 可以杀死任意进程，不能被捕获或忽略（俗称酒杀）。

SIGSEGV 11 无效的内存引用（segmentation fault）。 SIGPIPE 13 对于socket fd，当一个进程向某个已经收到RST的fd执行写操作时，内核会向该进程发送该信号。 SIGTERM 15 kill命令发送的默认终止信号。 SIGCHLD 17 进程终止时向其父进程发送的信号。

信号处理函数signal与signalaction

signal或者sigaction函数都可以用来进行信号处理，但signal函数太过古老，因此推荐使用sigaction。理由如下：

1. sigaction可以提供更多接收到信号的信息。

2. 调用完信号处理函数后重新设置处理函数不会对sigaction有影响，因为sigaction默认是不会去重置处理函数的，同时在执行处理函数会屏蔽掉该信号，也不会有竞争。 3. signal函数在某些系统中会默认重启被中断的系统调用，而sigaction默认不会这样做。 4. signal函数在多线程环境中的行为是未定义的，必须使用sigaction函数。

数据传输与信号

使用了系统调用的函数都有可能被信号中断，立刻返回的函数则（不需要等待I/O操作的完成或sleep）不会被中断，而需要等待的函数（等待网络传输，管道的读或者sleep）将会被中断，比如select, read, connect。
在daemon程序中，恰当地处理被中断的系统调用是非常重要的。如果read, write等传输数据的函数被中断，必须处理这种情况并恢复数据的传输。有两种被中断的场景：
1. 当没有数据传输时就被中断，函数返回-1，这时可以通过判断errno的值来识别这种错误，如果errno == EINTR，则表示函数在没有任何数据传输的情况下就被中断，这时可以通过同样的参数来再次调用该数据。
2. 另一种情况是数据传输已经在进行，但在没有完成之前被中断；这种情况下函数不会返回错误，而是返回一个小于期望大小的值，同时errno也不会有错误设置，想识别这种情况只能捕获导致中断的信号。在中断之后恢复数据传输时一定记得部分数据已经被传输，必须从正确的偏移再次发起传输。
不要通过sigaction函数设置SA_RESTART来处理被中断的系统调用。