I am using Debian stretch (systemd).
I was running the rsyslog daemon in foreground using
/usr/sbin/rsyslogd -n
and 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 toSIGTERM
? 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?
Best Answer
SIGSTOP
andSIGKILL
are two signals that cannot be caught and handled by a process.SIGTSTP
is likeSIGSTOP
except that it can be caught and handled.The
SIGSTOP
andSIGTSTP
signals stop a process in its tracks, ready forSIGCONT
. When you send that process aSIGTERM
, the process isn't running and so it cannot run the code to exit.(There are also
SIGTTIN
andSIGTTOU
, 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 likeSIGTSTP
. 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 byrsyslogd
, so it simply suspends the process pendingSIGCONT
orSIGKILL
.The solution here is also to send
SIGCONT
after yourSIGTERM
so that the process can receive and handle the signal.Example:
The documentation for the GNU C Library explains this quite well, I think (my highlighting):