Linux Signal 信号

Linux Signal的简表

转载来源: https://www.renfei.net/posts/1003370

Linux支持POSIX标准信号和实时信号。下面给出Linux Signal的简表:

一些信号的取值是硬件结构相关的（一般alpha和sparc架构用第一个值，i386、ppc和sh架构用中间值，mips架构用第三个值， – 表示相应架构的取值未知）。

SIGKILL和SIGSTOP信号不能被挂钩、阻塞或忽略。

在Linux 2.2（包括）内核之前，SIGSYS、SIGXCPU、SIGXFSZ和SIGBUS （SPARC和MIPS架构除外）的默认动作是终止进程，但没有core dump。Linux 2.4遵循POSIX.1-2001要求，这些信号的默认动作改为：终止进程同时做core dump。

进程可以通过使用sigaction和signal系统调用来改变信号的默认处理方式（使用signal的可移植性差）。进程可以选择下列3种信号处理方式中的一种：

1. 执行默认操作；
2. 忽略该信号；
3. 捕获该信号，但是通过信号句柄来调用自定义的处理函数。

信号可能被阻塞。进程中的每个线程拥有独立的信号掩码，用来表示本线程的信号被阻塞。线程通过pthread_sigmask来设置它的信号掩码。单线程程序可以用sigprocmask来操作信号掩码。在多线程程序中，所有线程处理一个指定信号的默认行为都是一样的。

部分汉化介绍

转载来源: https://blog.csdn.net/WJSZMD/article/details/89331751

SIGHUP     终止进程     终端线路挂断
SIGINT     终止进程     中断进程
SIGQUIT   建立CORE文件终止进程，并且生成core文件
SIGILL   建立CORE文件       非法指令
SIGTRAP   建立CORE文件       跟踪自陷
SIGBUS   建立CORE文件       总线错误
SIGSEGV   建立CORE文件       段非法错误
SIGFPE   建立CORE文件       浮点异常
SIGIOT   建立CORE文件       执行I/O自陷
SIGKILL   终止进程     杀死进程
SIGPIPE   终止进程     向一个没有读进程的管道写数据
SIGALARM   终止进程     计时器到时
SIGTERM   终止进程     软件终止信号
SIGSTOP   停止进程     非终端来的停止信号
SIGTSTP   停止进程     终端来的停止信号
SIGCONT   忽略信号     继续执行一个停止的进程
SIGURG   忽略信号     I/O紧急信号
SIGIO     忽略信号     描述符上可以进行I/O
SIGCHLD   忽略信号     当子进程停止或退出时通知父进程
SIGTTOU   停止进程     后台进程写终端
SIGTTIN   停止进程     后台进程读终端
SIGXGPU   终止进程     CPU时限超时
SIGXFSZ   终止进程     文件长度过长
SIGWINCH   忽略信号     窗口大小发生变化
SIGPROF   终止进程     统计分布图用计时器到时
SIGUSR1   终止进程     用户定义信号1
SIGUSR2   终止进程     用户定义信号2
SIGVTALRM 终止进程     虚拟计时器到时

SIGHUP 本信号在用户终端连接(正常或非正常)结束时发出, 通常是在终端的控制进程结束时, 通知同一session内的各个作业, 这时它们与控制终端不再关联. SIGINT 程序终止(interrupt)信号, 在用户键入INTR字符(通常是Ctrl-C)时发出 SIGQUIT 和SIGINT类似, 但由QUIT字符(通常是Ctrl-)来控制. 进程在因收到SIGQUIT退出时会产生core文件, 在这个意义上类似于一个程序错误信号. SIGILL 执行了非法指令. 通常是因为可执行文件本身出现错误, 或者试图执行数据段. 堆栈溢出时也有可能产生这个信号. SIGTRAP 由断点指令或其它trap指令产生. 由debugger使用.SIGABRT 程序自己发现错误并调用abort时产生. SIGIOT 在PDP-11上由iot指令产生, 在其它机器上和SIGABRT一样. SIGBUS 非法地址, 包括内存地址对齐(alignment)出错. eg: 访问一个四个字长的整数, 但其地址不是4的倍数. SIGFPE 在发生致命的算术运算错误时发出. 不仅包括浮点运算错误, 还包括溢出及除数为0等其它所有的算术的错误. SIGKILL 用来立即结束程序的运行. 本信号不能被阻塞, 处理和忽略. SIGUSR1 留给用户使用 SIGSEGV 试图访问未分配给自己的内存, 或试图往没有写权限的内存地址写数据. SIGUSR2 留给用户使用 SIGPIPE Broken pipe SIGALRM 时钟定时信号, 计算的是实际的时间或时钟时间. alarm函数使用该信号. SIGTERM 程序结束(terminate)信号, 与SIGKILL不同的是该信号可以被阻塞和处理. 通常用来要求程序自己正常退出. shell命令kill缺省产生这个信号. SIGCHLD 子进程结束时, 父进程会收到这个信号. SIGCONT 让一个停止(stopped)的进程继续执行. 本信号不能被阻塞. 可以用一个handler来让程序在由stopped状态变为继续执行时完成特定的工作. 例如, 重新显示提示符 SIGSTOP 停止(stopped)进程的执行. 注意它和terminate以及interrupt的区别: 该进程还未结束, 只是暂停执行. 本信号不能被阻塞, 处理或忽略. SIGTSTP 停止进程的运行, 但该信号可以被处理和忽略. 用户键入SUSP字符时(通常是Ctrl-Z)发出这个信号 SIGTTIN 当后台作业要从用户终端读数据时, 该作业中的所有进程会收到SIGTTIN信号. 缺省时这些进程会停止执行. SIGTTOU 类似于SIGTTIN, 但在写终端(或修改终端模式)时收到. SIGURG 有“紧急”数据或out-of-band数据到达socket时产生. SIGXCPU 超过CPU时间资源限制. 这个限制可以由getrlimit/setrlimit来读取/改变 SIGXFSZ 超过文件大小资源限制. SIGVTALRM 虚拟时钟信号. 类似于SIGALRM, 但是计算的是该进程占用的CPU时间. SIGPROF 类似于SIGALRM/SIGVTALRM, 但包括该进程用的CPU时间以及系统调用的时间. SIGWINCH 窗口大小改变时发出. SIGIO 文件描述符准备就绪, 可以开始进行输入/输出操作. SIGPWR Power failure

SIGINT,SIGKILL,SIGTERM信号区别

转载来源: https://blog.csdn.net/WJSZMD/article/details/89331751

SIGINT,SIGKILL,SIGTERM

三者都是结束/终止进程运行.但略微有区别.

SIGINT

产生方式: 键盘Ctrl+C 产生结果: 只对当前前台进程,和他的所在的进程组的每个进程都发送SIGINT信号,之后这些进程会执行信号处理程序再终止.

SIGTERM

产生方式: 和任何控制字符无关,用kill函数发送 本质: 相当于shell> kill不加-9时 pid. 产生结果: 当前进程会收到信号,而其子进程不会收到.如果当前进程被kill(即收到SIGTERM),则其子进程的父进程将为init,即pid为1的进程. 与SIGKILL的不同: SIGTERM可以被阻塞,忽略,捕获,也就是说可以进行信号处理程序,那么这样就可以让进程很好的终止,允许清理和关闭文件.

SIGKILL

产生方式: 和任何控制字符无关,用kill函数发送 本质: 相当于shell> kill -9 pid. 产生结果: 当前进程收到该信号,注意该信号时无法被捕获的,也就是说进程无法执行信号处理程序,会直接发送默认行为,也就是直接退出.这也就是为何kill -9 pid一定能杀死程序的原因. 故这也造成了进程被结束前无法清理或者关闭资源等行为,这样时不好的. 注意 由于SIGINT, SIGTERM都是可以被捕获的,也就是会执行信号处理函数的,故按照信号处理函数逻辑,可能进程不会退出,即不一定能终止,所以要处理好exit(0).

总结

SIGQUIT： 在POSIX兼容平台上，SIGQUIT是当用户请求进程执行核心转储时由其控制终端发送到进程的信号。 SIGQUIT通常可以用Control- \诱导。在Linux上，也可以使用Ctrl-4或在虚拟控制台上使用SysRq密钥。

SIGTERM： SIGTERM是kill或killall命令发送到进程的默认信号。它会导致进程终止，但与SIGKILL信号不同，进程可以捕获并解释（或忽略）它。因此，SIGTERM类似于要求进程很好地终止，允许清理和关闭文件。出于这个原因，在关闭期间的许多Unix系统上，init向所有对关闭电源不重要的进程发出SIGTERM，等待几秒钟，然后发出SIGKILL强制终止剩余的任何此类进程。

SIGINT： 在POSIX兼容平台上，SIGINT是当用户希望中断进程时由其控制终端发送给进程的信号。当进程’控制终端上的用户按下正在运行的进程密钥 – 通常是Control-C，但在某些系统上，“删除”字符或“中断”键时，发送SIGINT。

SIGKILL： 在POSIX兼容平台上，SIGKILL是发送给进程的信号，使其立即终止。当发送到程序时，SIGKILL会立即终止它。与SIGTERM和SIGINT相反，此信号无法捕获或忽略，接收过程无法在接收到此信号时执行任何清理。

killall 、kill 、pkill三个命令之间的区别

转载来源: 直接来源 https://cloud.tencent.com/developer/article/1847239, 最初来源: 微信公众号 – 浩Coding（gh_c4a2e63d2ca7），作者：浩

首先三个命令都是用于杀掉进程的，不过kill是杀掉单个进程，killall是杀掉所有同名进程，pkill是杀掉一类进程或者某个用户的所有进程。

一、kill命令

kill 命令的用途

kill 命令很容易让人产生误解，以为它仅仅就是用来杀死进程的。我们来看一下 man page 对它的解释：kill – send a signal to a process.从官方的解释不难看出，kill 是向进程发送信号的命令。当然我们可以向进程发送一个终止运行的信号，此时的 kill 命令才是名至实归。事实上如果我们不给 kill 命令传递信号参数，它默认传递终止进程运行的信号给进程！这是 kill 命令最主要的用法，也是本文要介绍的内容。

一般情况下，终止一个前台进程使用 Ctrl + C 就可以了。对于一个后台进程就得用 kill 命令来终止。我们会先使用 ps、top 等命令获得进程的 PID，然后使用 kill 命令来杀掉该进程。

kill 命令格式

使用kill -l命令列出所有可用的信号。

最常被使用的信号是1/9/15：

1（HUP）：重新加载进程。
9 (KILL)：杀死进程。
15（TERM）：完美地停止一个进程。
kill pid //同下-15默认的安全停止进程
kill -15 pid //
kill -9 pid  //彻底杀死进程

使用信号 15 是安全的，而信号 9 则是处理异常进程的最后手段，这样结束掉的进程不会进行资源的清理工作，所以如果你用它来终结掉 vim 的进程，就会发现临时文件 *.swp 没有被删除。

二、killall命令

Linux killall （kill processes by name）用于杀死进程，与 kill 不同的是killall 会杀死指定名字的所有进程。kill 命令杀死指定进程 PID，需要配合 ps 使用，而 killall 直接对进程对名字进行操作，更加方便。

killall -9 mysql         //结束所有的 mysql 进程

三、pkill命令

pkill 命令和 killall 命令的用法相同，都是通过进程名杀死一类进程，除此之外，pkill 还有一个更重要的功能，即按照终端号来踢出用户登录。

pkill mysql         //结束 mysql 进程
pkill -u mark,danny //结束mark,danny用户的所有进程
w  //#使用w命令查询本机已经登录的用户
pkill -9 -t pts/1  //#强制杀死从pts/1虚拟终端登陆的进程

四、拓展命令

如果能看懂下面一系列命令，那么killall 、kill 、pkill三个命令之间的区别你也就了然于胸了。

1、pgrep命令：专门显示进程的进程号，相当于：

ps -aux | grep 进程名 | grep -v grep| awk '{print $2}' 

2、pidof命令：pid of xx进程，显示进程的进程号，同上pgrep。

3、组合命令的使用：

pgrep mysql | xargs kill -s 9
ps -ef | grep mysql | grep -v grep | awk '{print $2}' | xargs kill -9
kill -s 9 `pgrep mysql`

看到上面这三条命令的转换想到了什么吗，联想下pkill命令：pkill＝pgrep+kill。

pkill与kill在这点的差别是：pkill无须 “ｓ”，终止信号等级直接跟在 “-“ 后面。之前我一直以为是 “-s 9”，结果每次运行都无法终止进程。

killall和pkill是相似的，不过如果给出的进程名不完整，killall会报错。pkill或者pgrep只要给出进程名的一部分就可以终止进程。

Linux 如何杀死一个进程和它的所有子进程

• 原文地址：Killing a process and all of its descendants
• 原文作者：igor_sarcevic
• 译文出自：掘金翻译计划
• 本文永久链接：https://github.com/xitu/gold-miner/blob/master/TODO1/killing-a-process-and-all-of-its-descendants.md
• 译者：江五渣
• 校对者：TokenJan，portandbridge

如何杀死一个进程和它的所有子进程

在类 Unix 系统中杀死进程比预期中更棘手。上周我在调试一个在 Semaphore 中终止作业的问题。更具体地说，这是一个有关于在作业中终止正在运行的进程的问题。以下是我从中学到的要点：

• 类 Unix 操作系统有着复杂的进程间关系：父子进程、进程组、会话、会话的领导进程。但是，在 Linux 与 MacOS 等操作系统中，这其中的细节并不统一。符合 POSIX 的操作系统支持使用负 PID 向进程组发送信号。
• 使用系统调用向会话中的所有进程发送信号并非易事。
• 用 exec 启动的子进程将继承其父进程的信号配置。例如，如果父进程忽略 SIGHUP 信号，它的子进程也会忽略 SIGHUP 信号。
• “孤儿进程组内发生了什么”这一问题的答案并不简单。

杀死父进程并不会同时杀死子进程

每个进程都有一个父进程。我们可以使用 pstree 或 ps 工具来观察这一点。

# 启动两个虚拟进程
$ sleep 100 &
$ sleep 101 &
$ pstree -p
init(1)-+
        |-bash(29051)-+-pstree(29251)
                      |-sleep(28919)
                      `-sleep(28964)
$ ps j -A
 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
    0     1     1     1 ?           -1 Ss       0   0:03 /sbin/init
29051  1470  1470 29051 pts/2     2386 SN    1000   0:00 sleep 100
29051  1538  1538 29051 pts/2     2386 SN    1000   0:00 sleep 101
29051  2386  2386 29051 pts/2     2386 R+    1000   0:00 ps j -A
    1 29051 29051 29051 pts/2     2386 Ss    1000   0:00 -bash

调用 ps 命令可以显示 PID（进程 ID） 和 PPID（父进程 ID）。

我对父子进程间的关系有着错误的假设。我认为如果我杀死了父进程，那么也会杀死它的所有子进程。然而这是错误的。相反，子进程将会成为孤儿进程，而 init 进程将重新成为它们的父进程。

让我们看看通过终止 bash 进程（sleep 命令的当前父进程）来重建进程间的父子关系后发生了哪些变化。

$ kill 29051 # 杀死 bash 进程
$ pstree -A
init(1)-+
        |-sleep(28919)
        `-sleep(28965)

于我而言，重新分配父进程的行为很奇怪。例如，当我使用 SSH 登录一台服务器，启动一个进程，然后退出时，我启动的进程将会被终止。我错误地认为这是 Linux 上的默认行为。当我离开一个 SSH 会话时，进程的终止与进程组、会话的领导进程和控制终端都有关。

什么是进程组和会话领导进程？

让我们再次观察上述事例中 ps j 命令的输出。

$ ps j -A
 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
    0     1     1     1 ?           -1 Ss       0   0:03 /sbin/init
29051  1470  1470 29051 pts/2     2386 SN    1000   0:00 sleep 100
29051  1538  1538 29051 pts/2     2386 SN    1000   0:00 sleep 101
29051  2386  2386 29051 pts/2     2386 R+    1000   0:00 ps j -A
    1 29051 29051 29051 pts/2     2386 Ss    1000   0:00 -bash

除了使用 PPID 和 PID 表示的父子进程关系外，进程间还有其他两种关系：

• 用 PGID 表示的进程组
• 用 SID 表示的会话

我们可以在支持作业控制的 Shell 环境中观察到进程组，例如 bash 和 zsh，它们为每个管道命令都创建了一个进程组。进程组是一个或多个进程（通常与一个作业关联）的集合，可以从同一个终端接收信号。每个进程组都有一个唯一的进程组 ID。

# 启动一个由 tail 和 grep 命令组成的进程组
$ tail -f /var/log/syslog | grep "CRON" &
$ ps j
 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
29051 19701 19701 29051 pts/2    19784 SN    1000   0:00 tail -f /var/log/syslog
29051 19702 19701 29051 pts/2    19784 SN    1000   0:00 grep CRON
29051 19784 19784 29051 pts/2    19784 R+    1000   0:00 ps j
29050 29051 29051 29051 pts/2    19784 Ss    1000   0:00 -bash

请注意，在前半段中，tail 和 grep 的 PGID 是相同的。

会话是进程组的集合，通常由一个控制终端和一个会话领导进程组成。如果会话中有一个控制终端，它就具有单个前台进程组，除了该控制终端，会话中的所有其他进程组都是后台进程组。

并非所有的 bash 进程都是会话，但是当你使用 SSH 登录一台远程服务器时，你通常会得到一个会话。当 bash 作为会话领导进程运行时，它将 SIGHUP 信号传播给它的子进程。SIGHUP 信号的传播方式就是我一直以来坚信子进程会与父进程一起消亡的核心原因。

在 Unix 中会话的实现并非一致

在上述事例中，你可以注意到 SID （进程的会话 ID）出现的位置。它是会话中所有进程共享的 ID。

但是，你需要记住，并非所有的 Unix 系统都遵循这一实现。单一 UNIX 规范只讨论“会话领导进程”，没有类似于进程 ID 或进程组 ID 的“会话 ID”。会话领导进程是一个具有唯一进程 ID 的单进程，因此我们可以讨论的会话 ID 是会话领导者的进程 ID。

System V Release 4 引入了会话 ID。

实际上，这意味着你能在 Linux 上通过 ps 命令获取会话 ID，但是在 BSD 及其变体（如 MacOS）上，会话 ID 并不存在，或始终为零。

杀死进程组或会话中的所有进程

我们可以使用该 PGID，通过 kill 命令向整个进程组发送信号：

$ kill -SIGTERM -- -19701

我们用一个负数 -19701 向进程组发送信号。如果我们传递的是一个正数，这个数将被视为进程 ID 用于终止进程。如果我们传递的是一个负数，它被视为 PGID，用于终止整个进程组。

负数来自系统调用的直接定义。

杀死会话中的所有进程与之完全不同。如我们在前一节说到的，有些系统没有会话 ID 的概念。即使是具有会话 ID 的系统，例如 Linux，也没有提供系统调用来终止会话中的所有进程。你需要遍历 /proc 输出的进程树，收集所有的 SID，然后一一终止进程。

Pgrep 实现了遍历、收集并通过会话 ID 杀死进程的算法。使用以下命令：

pkill -s <SID>

被 nohup 忽略的信号传播到子进程

被忽略的信号，就像是被 nohup 忽略的信号那样，都被传播到进程的所有子进程中。这种信号传播方式就是我上周在 bug 排查中遇到的最终瓶颈。

我的程序是用于运行 bash 命令的代理程序，而我在该程序中验证到的是，我已经建立了一个具有控制终端的 bash 会话。该控制终端是 bash 会话中其他启动进程的会话领导进程。我的进程树如下所示：

agent -+
       +- bash (session leader) -+
                                 | - process1
                                 | - process2

我假设，当我使用 SIGHUP 杀死 bash 会话时，它的子进程也会同时终止。对代理的集成测试也证明了这一点。

但是，我忽略了这个代理是以 nohup 启动的。当你使用 exec 启动子进程时，就像我们在代理中启动 bash 进程一样，它会从它的父进程继承信号状态。

最后一个结论使我惊讶万分。