☰

在没有信号处理程序的情况下，SIGTERM 的行为是否与 SIGKILL 相同？

tag-icon • tag-icon process signals
在没有信号处理程序的情况下，SIGTERM 的行为是否与 SIGKILL 相同？

大多数 SIGTERM 和 SIGKILL 的描述都指出 SIGKILL，

与 SIGTERM 和 SIGINT 相比，[...] 不能被捕获或忽略 [...] (维基百科）

这是 SIGTERM 和 SIGKILL 之间的唯一区别吗？特别是，如果进程没有安装 SIGTERM 处理程序，向进程发送 SIGTERM 或 SIGKILL 之间有什么区别吗？

答案1

在没有任何信号配置的情况下，SIGTERM和SIGKILL至少从被终止进程的角度来看实际上是等效的，默认操作是终止进程的其他信号也是如此，包括SIGUSR1和SIGUSR2。作为伊尔卡丘指出，父进程被告知终止子进程的信号（这就是你的 shell 区分信号的方式，并打印例如“终止”v.“用户定义信号 1”）。

正如维基百科上提到的，SIGKILLcan’t be returned orignored，而SIGTERMcan;请注意，这意味着进程不需要安装处理程序即可SIGTERM无效，它可以简单地阻止它或忽略它（请参阅sighold()，sigrelse()和sigignore()）。

POSIX 的详细部分信号处理背后的基本原理。 Linuxsignal(7)联机帮助页也详细记录了信号。

答案2

这是 SIGTERM 和 SIGKILL 之间的唯一区别吗？

不。

SIGKILLa和 uncaught之间的一个很大的区别SIGTERM是前者也会醒来一个停止的进程（因此它可以立即销毁自己），而后者仅在SIGCONT.

简单的例子：

$ sleep 1000 & sleep 1; kill -TSTP $!
[1] 6455

[1]+  Stopped                 sleep 1000
$ kill -TERM 6455
$ jobs
[1]+  Stopped                 sleep 1000
$ kill -CONT 6455
$ jobs
[1]+  Terminated              sleep 1000

如果您想确保您的TERM、HUP、INT等信号有任何效果，您应该将其与CONT信号配对（以任何顺序）。

人们可能不容易明白这一点，因为 bash 内置函数的魔力kill——当与作业 id 一起使用时，如%或%1（或否定 pid）指的是已停止的进程工作， 它会自己做这一切窗帘后面：

/* Give PID SIGNAL.  This determines what job the pid belongs to (if any).
   If PID does belong to a job, and the job is stopped, then CONTinue the
   job after giving it SIGNAL.  Returns -1 on failure.  If GROUP is non-null,
   then kill the process group associated with PID. */
int
kill_pid (pid, sig, group)

相关内容