为什么我不能用SIGTERM终止SIGSTOP的进程，并且将待处理信号存储在哪里？

我正在使用Debian Stretch（systemd）。我在前台使用rsyslog守护程序运行 /usr/sbin/rsyslogd -n ，我做了一个Ctrl+ Z来停止它。进程的状态更改为Tl（已停止，已线程化）。我向流程发出了多个命令，流程的状态是相同的：。一旦我做了一个，它就死了。我有3个问题。kill -15 <pid>Tlfg

• 为什么SIGSTOP-ed过程没有响应SIGTERM？为什么内核将其保持在相同状态？
• 为什么收到SIGCONT信号后就被杀死了？
• 如果是由于先前的SIGTERM信号，在恢复过程之前将其保存在哪里？

SIGSTOP并且SIGKILL是不能被捕获，并通过一个过程来处理两个信号。SIGTSTP就像SIGSTOP不同的是它可以捕捉和处理。

该SIGSTOP和SIGTSTP在其轨道的信号停止一个进程，准备好SIGCONT。当您发送该进程a时SIGTERM，该进程未运行，因此无法运行代码以退出。

（还有SIGTTIN和SIGTTOU，这是TTY层在后台作业尝试读取或写入终端时由TTY层生成的信号。可以捕获它们，但是将停止（挂起）该过程，就像SIGTSTP。但是，我现在要去忽略其余两个答案。）

您CtrlZ发送的进程a SIGTSTP似乎并没有以任何方式进行特殊处理rsyslogd，因此它只是挂起挂起的进程SIGCONT或SIGKILL。

这里的解决方案也是SIGCONT在您之后发送，SIGTERM以便进程可以接收和处理信号。

例：

sleep 999 &

# Assume we got PID 456 for this process
kill -TSTP 456    # Suspend the process (nicely)
kill -TERM 456    # Terminate the process (nicely). Nothing happens
kill -CONT 456    # Continue the process so it can exit cleanly

我认为，GNU C库的文档很好地解释了这一点（重点介绍）：

当一个过程停止时，除了SIGKILL信号和（显然）SIGCONT信号之外，没有其他信号可以传递给它，直到继续执行为止。信号被标记为未决，但直到继续处理才交付。该SIGKILL信号始终导致过程终止，并且不能被阻塞，处理或忽略。您可以忽略SIGCONT，但是如果停止，它总是使该过程继续进行。向SIGCONT过程发送信号会导致该过程的任何挂起的停止信号被丢弃。同样，SIGCONT当进程接收到停止信号时，该进程的任何挂起信号都将被丢弃

SIGTERM就像任何其他信号一样，它可以被进程捕获。接收信号只会使过程跳到特殊的信号处理程序例程。对于SIGTERM默认操作，将终止该过程，但是例如，编辑者可能希望捕获信号，以便它可以在死亡之前保存所有打开文件的草稿副本。如果进程停止，则无法运行信号处理程序，但是信号将保持挂起状态，直到进程继续。请注意，通常不会保存发送的信号数量。

从理论上讲，系统可以知道进程是否为安装了信号处理程序SIGTERM，如果没有，则立即终止。但是（根据Gilles的评论），POSIX要求信号将持续发送，直到通过继续该过程SIGCONT。