Linux信号SIGTERM、SIGKILL、SIGINT和SIGQUIT的区别；posix_kill使用

SIGTERM是不带参数时kill发送的信号，意思是要进程终止运行，但执行与否还得看进程是否支持。但是SIGKILL信号不同，它可以被捕获和解释（或忽略）的过程。
SIGKILL是发送到处理的信号以使其立即终止。当发送到程序，SIGKILL使其立即终止。在对比SIGTERM和SIGINT，这个信号不能被捕获或忽略，并且在接收过程中不能执行任何清理在接收到该信号。
SIGINT中断信号，终端在用户按下CTRL+C发送到前台进程。默认行为是终止进程，但它可以捕获或忽略。
SIGQUIT是其控制终端发送到进程，当用户请求的过程中执行核心转储的信号。 SIGQUIT通常可以ctrl+/。它可以被捕获和解释（或忽略）。

合适：

遇到信号量的问题？

 signal(SIGCLD,SIG_IGN)

SIGCHLD的语义为:子进程状态改变后产生此信号，父进程需要调用一个wait函数以确定发生了什么。

 对于SIGCLD的早期处理方式如下:如果进程特地设置该信号的配置为SIG_IGN,则调用进程的子进程将不产生僵死进程。

 如果将SIGCLD的配置设置为捕捉，则内核立即检查是否有子进程准备好被等待，如果是这样，则调用SIGCLD处理程序。

APUE上SIGCLD语义写的有点不清楚，到底我们的系统是如何来处理SIGCLD信号呢？
    1.SIG_DFL ：默认的处理方式是不理会这个信号，但是也不会丢弃子进行状态，所以如果不用wait，waitpid

对其子进行进行状态信息回收，会产生僵尸进程。
    2.SIG_IGN ：忽略的处理方式，这个方式和默认的忽略是不一样的语意，暂且我们把忽略定义为SIG_IGN，

在这种方式下，子进程状态信息会被丢弃，也就是自动回收了，所以不会产生僵尸进程，但是问题也就来了，

wait，waitpid却无法捕捉到子进程状态信息了，如果你随后调用了wait，那么会阻塞到所有的子进程结束，并返

回错误ECHILD，也就是没有子进程等待。
       APUE中P248叙述SIGCHLD如果配置成SIG_IGN也不会产生僵尸进程。是否系统SIG_IGN配置下，对

SIGCLD，SIGCHLD做出的处理方式是相同的。
   3.自定义处理方式：SIGCLD会立即检查是否有子进程准好被等待，这便是SIGCLD最大漏洞了，一旦在信号

处理函数中加入了信号处理方式重建的步骤，那么每次设置SIGCLD处理方式时，都会去检查是否有信号到来，

如果此时信号的确到来了，先是调用自定义信号处理函数，然后是调用信号处理方式重建函数，在重建配置的

时候，会去检查信号是否到来，此时信号未被处理，会再次触发自定义信号处理函数，一直循环。

    所以在处理SIGCLD时，应该先wait处理掉了信号信息后，再进行信号处理方式重建。

   SIGCHLD在配置信号处理方式时，是不会立即检查是否有子进程准备好被扽带，也不会在此时调用信号处理函数。

 

 

https://blog.csdn.net/u012317833/article/details/39253793