信号SIGKILL和SIGSTOP无法被捕获，阻止或无法识别，为什么？
我想知道为什么在这个过程中无法捕获，阻止或忽略这两个信号？ 可以使用signal（）更改剩余信号的动作。 这两个信号和剩余信号有什么区别？
如果你谈到他们被阻止的原因，那么@Adam B已经提到了原因。但是我想展示一些内部结构。 它不是你不能真正阻止这两个信号。 只有KERNEL有能力做到这一点，而不是我们。
在signal.h的实现中，你可以看到有这样一行
#define SIG_KERNEL_ONLY_MASK (rt_sigmask(SIGKILL) | rt_sigmask(SIGSTOP))
这表明这两个信号只能由内核屏蔽 。
另一个宏环绕着它
#define sig_kernel_only(sig) (((sig) < SIGRTMIN) && siginmask(sig, SIG_KERNEL_ONLY_MASK))
后来用于signal.c ..
一个名为do_sigaction函数在收到任何具有负值的信号或任何除内核之外不处理的信号时返回EINVAL 。
看看这个
if (!valid_signal(sig) || sig < 1 || (act && sig_kernel_only(sig))) return -EINVAL;
显然，系统比我们想象的更复杂，但这只是一瞥，只表明只允许KERNEL处理这些信号。 不是我们。 除此之外，在function的实现中没有什么神奇之处。
@R Sahu也谈到了这方面非常重要的一个方面。 还应限制root用户执行某些可能对系统有害的操作。 此外，当你没有选择或选择杀死它时，可以终止一些无响应或错误的应用程序。 谨慎使用SIGKILL或SIGSTOP。因为大多数时候这些都不能处理内存清理和其他内务管理的东西......使用这两个只有当你没有其他选择时......这里的SIGTERM更受欢迎
这些由内核处理。 它们用于杀死无响应的任务（应用程序）。
当您的应用程序本身没有响应时，应该有一些方法可以退出应用程序。 由于您的任务无法在此状态下处理任何事情，因此应该有一种方式信号发送到无响应的任务，但不会由无响应的任务处理。
SIGKILL和SIGSTOP用于此过程。
这就是man page说的原因
“信号SIGKILL和SIGSTOP无法被捕获，阻止或忽略。”
这些由内核为您处理。 您可以根据自己的特定需求使用大量信号/实时信号。