Why can't I kill a SIGSTOP'd process with a SIGTERM, and where is the pending signal stored?
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 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
The 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. TheSIGKILL
signal always causes termination of the process and can’t be blocked, handled or ignored. You can ignoreSIGCONT
, but it always causes the process to be continued anyway if it is stopped. Sending aSIGCONT
signal to a process causes any pending stop signals for that process to be discarded. Likewise, any pendingSIGCONT
signals for a process are discarded when it receives a stop signal
SIGTERM
is just like any other signal in that it can be caught by a process. Receiving the signal will just make the process jump to a special signal handler routine. For SIGTERM
the default action will be to terminate the process, but e.g. an editor might like to catch the signal so it can save a draft copy of any open files before dying. If the process is stopped, it cannot run the signal handler, but the signal will remain pending until the process continues. Note that the number of signals sent will usually not be saved.
In theory, the system could know if the process has a signal handler installed for SIGTERM
, and terminate it immediately if not. But (as per Gilles' comment) POSIX demands that the signal will pend until the process is continued via SIGCONT
.