I am using Debian stretch (systemd).I was running the rsyslog daemon in foreground using/usr/sbin/rsyslogd -nand I did a Ctrl+Z to stop it. The state of the process changed to Tl (stopped, threaded).I issued multiple kill -15 <pid> commands to the process, and the state of the process was the same: Tl. Once I did an fg, it died. I have 3 questions.Why was the SIGSTOP-ed process not responding to SIGTERM? Why does the kernel keeps it in the same state? Why did it get killed the moment it received the SIGCONT signal?If it was because of the previous SIGTERM signal, where was it kept until the process resumed?
Why can't I kill a SIGSTOP'd process with a SIGTERM, and where is the pending signal stored?
process;kill;signals
SIGSTOP and SIGKILL are two signals that cannot be caught and handled by a process. SIGTSTP is like SIGSTOP except that it can be caught and handled.The SIGSTOP and SIGTSTP signals stop a process in its tracks, ready for SIGCONT. When you send that process a SIGTERM, the process isn't running and so it cannot run the code to exit.(There are also SIGTTIN and SIGTTOU, which are signals generated by the TTY layer when a backgrounded job tries to read or write to the terminal. They can be caught but will otherwise stop (suspend) the process, just like SIGTSTP. But I'm now going to ignore those two for the remainder of this answer.)Your CtrlZ sends the process a SIGTSTP, which appears not to be handled specially in any way by rsyslogd, so it simply suspends the process pending SIGCONT or SIGKILL.The solution here is also to send SIGCONT after your SIGTERM so that the process can receive and handle the signal.Example:sleep 999 &# Assume we got PID 456 for this processkill -TSTP 456    # Suspend the process (nicely)kill -TERM 456    # Terminate the process (nicely). Nothing happenskill -CONT 456    # Continue the process so it can exit cleanlyThe documentation for the GNU C Library explains this quite well, I think (my highlighting):While a process is stopped, no more signals can be delivered to it until it is continued, except SIGKILL signals and (obviously) SIGCONT signals. The signals are marked as pending, but not delivered until the process is continued. The SIGKILL signal always causes termination of the process and cant be blocked, handled or ignored. You can ignore SIGCONT, but it always causes the process to be continued anyway if it is stopped. Sending a SIGCONT signal to a process causes any pending stop signals for that process to be discarded. Likewise, any pending SIGCONT signals for a process are discarded when it receives a stop signal