跟结束进程相关的那些信号

前言

项目中在使用kube-keepalived-vip时遇到了keepalived相关的Bug, 本来计划测试最新版的keepalived看是否存在一样的问题. 在将keepalived升级到当前最新版本v2.0.7以后发现每次执行kubectl delete pod <kube-keepalived-vip pod>都会出现segfault的内核错误, 且较大几率会连带出现keepalived的僵尸进程, 但对比发现经过手动执行kill -9结束keepalived进程却没有这个问题. 翻了一下runc的代码发现kubectl delete实际上(默认状况)是经过发给进程一个SIGTERM的信号让其退出, 这就是为何手动执行kill -9没有出现一样的问题. 这里索性整理了一下与结束进程相关的信号的区别和联系.

信号

• 什么是信号

• 信号是软件中断, 不少比较重要的应用程序都须要处理信号. 信号提供了一种处理异步事件的方法. 例如, 终端用于键入中断健, 会经过信号机制中止一个程序, 或及早终止管道中的下一个程序.
• UNIX系统的早期版本就已经提供信号机制, 可是这些系统(V7)所提供的信号模型并不可靠. 信号可能丢失, 而且在执行临界区代码时, 进程很难关闭所选择的信号. 4.3BSD和SVR3对信号模型都作了修改, 增长了可靠信号机制. 可是Berkeley和AT&T所作的更改之间并不兼容. 幸运的是, POSIX.1对可靠信号例程进行了标准化.

• 查看信号列表

• 在Linux系统当中可直接经过kill命令加-l参数列出全部的信号, 主要依据头文件/usr/include/linux/signal.h.
• 能够看到全部的信号都包含一个正整数序号(序号0有特殊用途)和一个以SIG开头的简称

[root@10-10-88-192 ~]# kill -l
 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
[root@10-10-88-192 ~]#

结束进程相关的信号

经过kill -l能够看到操做系统总共提供了64种信号, 这里只列举了与结束进程相关的几种信号, 分别是信号序号为一、二、三、九、15的SIGHUP、SIGINT、SIGKILL、SIGTERM

• SIGHUP

  • 若是终端接口检测到一个链接断开, 则将此信号送给与该终端相关的控制进程. (与之相关的命令为nohup)
  • 若是终端会话首进程终止, 也产生此信号. 在这种状况下, 此信号送给前台进程组中的每个进程.
  • 一般用此信号通知守护进程再次读取它们的配置文件. 选用SIGHUP的理由是, 守护进程不会有控制终端, 一般毫不会接收到这种信号.
  • 这也是kube-keepalived-vip当中reload keepalived.conf的方式

kill -1 <pid>

• SIGINT

  • 用户按下中断健(通常采用DELETE或Ctrl+C)时, 终端驱动程序产生此信号并发送至前台进程组中的每个进程.
  • 当一个进程组在运行时失控, 特别是当进程正在屏幕上产生大量不须要的输出时, 经常使用此信号终止.

kill -2 <pid>

• SIGQUIT

  • 当用户在终端上按退出键(通常采用Ctrl +  ), 中断驱动程序产生此信号, 并发送给前台进程组中的全部进程.
  • 此信号不只终止前台进程组(如SIGINT), 同时将产生一个core文件(关于如何查看core文件, 见另外一片博文《如何查看core文件》).
  • 设计的初衷为以较温和地方式退出程序, 让程序在退出前能够清理一些临时文件或者作别的处理, 但建议最好很差清理临时文件, 方便gdb配合core文件进行Debug.

kill -3 <pid>

• SIGKILL

  • 强制当即结束进程, 相较于其余信号, SIGKILL信号不可以被进程捕获, 也不可以被忽略, 所以老是可以结束进程(若是不行, 那必定是操做系统的Bug).
  • 不可以阻塞该信号
  • 使用该信号必定要想清楚后果

kill -9 <pid>

• SIGTERM

  • kill命令默认发送的终止信号.
  • 该信号可由应用程序捕获, 故使用SIGTERM也让程序有机会在退出以前作好清理工做, 从而优雅地终止.

kill -15 <pid>

结束语

不少时候不少莫名其妙的问题或者Bug都是由于咱们对一些细节的不理解或者掌握的不够透彻, 就好比结束一个进程就有这么多种方式, 你是否每一种方式都可以说清楚呢? 基础是否夯实正是从平常工做的小事积累和体现出来.

参考

1. https://www.gnu.org/software/libc/manual/html_node/Termination-Signals.html
2. 《Unix环境高级编程》
3. Linux man page