How can I kill my backticked yes process?

Question

I was playing around in my terminal, which runs zsh. I typed the following:

$ `
bquote> yes
bquote> `

And then, yes started to run in the background, I think. Neither Ctrl + C nor Ctrl + \ worked to kill the process. I closed the terminal, but the process just seems to continue. All I can say is that I can confirm that my fan still works.

I've run the following commands, which don't work either:

• pkill yes
• pkill yes\ \<defunct\> (showed up when using Tab completion)
• killall -9 yes
• pkill zsh
• killall -9 zsh

I can't reboot my computer because there's a large file being copied to another computer and I don't want to restart that process.

Here's my top output:

top - 16:06:16 up  7:41,  3 users,  load average: 1,49, 1,33, 1,02
Tasks: 305 total,   3 running, 301 sleeping,   0 stopped,   1 zombie
%Cpu(s): 53,8 us,  2,5 sy,  0,0 ni, 43,5 id,  0,0 wa,  0,0 hi,  0,2 si,  0,0 st
KiB Mem:   6009896 total,  5897432 used,   112464 free,    17152 buffers
KiB Swap:  7811068 total,      280 used,  7810788 free.  2225944 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     
24814 john      20   0 2367448 2,219g   3896 R  98,9 38,7  12:29.00 zsh         
 2134 john      20   0 1576256 117104  69868 S   2,7  1,9   2:44.03 compiz      
 1163 root      20   0  311032  66020  25016 S   2,3  1,1   9:28.03 Xorg        
25428 john      20   0   30220   3800   3008 S   2,0  0,1   0:08.48 htop        
  408 root     -51   0       0      0      0 S   1,3  0,0   4:25.59 irq/32-iwl+ 
25359 john      20   0  581928  31888  25080 S   1,3  0,5   0:00.92 gnome-term+ 
 2051 john      20   0  653056  32296  23640 S   1,0  0,5   0:05.72 unity-pane+ 
25479 john      20   0   29276   3164   2544 R   0,7  0,1   0:00.04 top         
  819 message+  20   0   40748   4044   2372 S   0,3  0,1   0:04.27 dbus-daemon 
 1995 john      20   0  363388  10984   5828 S   0,3  0,2   0:20.36 ibus-daemon 
 2049 john      20   0   39252   3544   3016 S   0,3  0,1   0:00.27 dbus-daemon 
 2103 john      20   0  205408   6516   5936 S   0,3  0,1   0:05.65 ibus-engin+ 
 2157 john      20   0  551436  10652   8376 S   0,3  0,2   0:01.35 indicator-+ 
24009 nobody    20   0  275852  14904  12260 S   0,3  0,2   0:23.73 smbd        
24536 root      20   0       0      0      0 S   0,3  0,0   0:00.33 kworker/u8+ 
    1 root      20   0   33888   4452   2720 S   0,0  0,1   0:01.67 init        
    2 root      20   0       0      0      0 S   0,0  0,0   0:00.00 kthreadd    

Here is my ps aux | grep yes output:

$ ps aux | grep yes
john     25004  0.1  0.0      0     0 ?        Z    15:53   0:01 [yes] <defunct>
john     25603  0.0  0.0  15976  2220 pts/25   S+   16:13   0:00 grep --color=auto yes

Answer 1

This answer on stackoverflow by Bill Karwin is exactly what you are looking for:

You have killed the process, but a dead process doesn't disappear from the process table until its parent process performs a task called "reaping" (essentially calling wait(3) for that process to read its exit status). Dead processes that haven't been reaped are called "zombie processes."

The parent process id you see for 31756 is process id 1, which always belongs to init. That process should reap its zombie processes periodically, but if it can't, they will remain zombies in the process table until you reboot.

Except in this case, the parent process is zsh. kill -9 the zsh process and the defunct yes will be gone.

Check out htop to get a better grasp for process ownership hierarchies (toggle flat/hierarchical view with t).

Answer 2

After killall -9 yes, and even after killall yes, the yes process is dead. When ps shows a process in state Z and with <defunct> afte the command name, that's not a process, that's a zombie. Zombies are dead and you can't kill them more.

What's going on here is that the yes process is dead. It isn't producing any more input. However the shell process that's executing the command substitution has read a lot of data and is very busy allocating memory for it (and perhaps not coping very efficiently with the huge amount of data).

Run ps -C yes l (Linux syntax) to see the parent process of yes. That's the one you need to kill. Another way to spot it is that it's the one taking 98.9% CPU time in that top output.