Shell – Why doesn’t SIGKILL terminate a stopped program (yes)

job-controlshell

I'm using Ubuntu 14.04 and I'm experiencing this behavior I can't seem to understand:

Run the yes command (in the default shell: Bash)
Type CtrlZ to stop yes
Run jobs. Output:
[1]+ Stopped yes
Run kill -9 %1 to stop yes. Output:
[1]+ Stopped yes
Run jobs. Output:
[1]+ Stopped yes

This is on Ubuntu 3.16.0-30-generic running in a parallels virtual machine.

Why didn't my kill -9 command terminate the yes command? I thought SIGKILL can't be caught or ignored? And how can I terminate the yes command?

Best Answer

Signals are blocked for suspended processes. In a terminal:

$ yes
...
y
y
^Zy

[1]+  Stopped                 yes

In a second terminal:

$ killall yes

In the first terminal:

$ jobs
[1]+  Stopped                 yes

$ fg
yes
Terminated

However SIGKILL can't be blocked. Doing the same thing with killall -9 yes from the second terminal immediately gives this in the yes terminal:

[1]+  Killed                  yes

Consequently if kill -9 %1 doesn't terminate the process right away then either bash isn't actually sending the signal until you fg the process, or you have uncovered a bug in kernel.

Related Solutions

Shell – Why is `kill -s INT ` behaving differently from `Ctrl-C`

Control-c from the terminal sends an interrupt signal to the process group associated with the terminal, which includes the sleep process. Sending SIGINT via kill only reaches one process, and in this case it happens to be the wrong process because $$ returns the process ID of the shell, not the sleep process. Shells normally ignore SIGINT.

Bash – Why Using yes in Pipelines Doesn’t Cause Infinite Loops

When true exits, the read side of the pipe is closed, but yes continues trying to write to the write side. This condition is called a "broken pipe", and it causes the kernel to send a SIGPIPE signal to yes. Since yes does nothing special about this signal, it will be killed. If it ignored the signal, its write call would fail with error code EPIPE. Programs that do that have to be prepared to notice EPIPE and stop writing, or they will go into an infinite loop.

If you do strace yes | true¹ you can see the kernel preparing for both possibilities:

write(1, "y\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\ny\n"..., 4096) = -1 EPIPE (Broken pipe)
--- SIGPIPE {si_signo=SIGPIPE, si_code=SI_USER, si_pid=17556, si_uid=1000} ---
+++ killed by SIGPIPE +++

strace is watching events via the debugger API, which first tells it about the system call returning with an error, and then about the signal. From yes's perspective, though, the signal happens first. (Technically, the signal is delivered after the kernel returns control to user space, but before any more machine instructions are executed, so the write "wrapper" function in the C library does not get a chance to set errno and return to the application.)

¹ Sadly, strace is Linux-specific. Most modern Unixes have some command that does something similar, but it often has a different name, it probably doesn't decode syscall arguments as thoroughly, and sometimes it only works for root.

Best Answer

Related Solutions

Shell – Why is `kill -s INT ` behaving differently from `Ctrl-C`

Bash – Why Using yes in Pipelines Doesn’t Cause Infinite Loops

Related Question