How to kill the backticked yes process

killprocesszsh

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

Best Answer

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).

Related Solutions

Process – How to Kill Both Process and Subprocess

There is a standard method, if the programs cooperate. Run kill -- -42 where 42 is the pid of the parent process. This sends a signal to all the processes in the process group lead by process 42 (the minus sign before the pid means process group).

Normally, if you run your python script from a shell prompt and it simply forks gnuchess, the two processes should remain in the same process group. But this doesn't seem to be the case, since Ctrl+C sends SIGINT to the whole foreground process group.

Gnuchess might be in its own process group because it made itself a session leader (but I don't know why it would do this), or because you've double-forked it (python forks a shell which forks gnuchess). A double fork is probably avoidable, but I can't tell you how without seeing your code.

A reasonably reliable and POSIX-compliant way of finding the pid of the gnuchess process is

gnuchess_pids=$(ps -A -o pid= -o cmd= | awk '$2 ~ /(^|\/)gnuchess$/ {print $1}')

Specific unix variants may have better ways of achieving this, such as pgrep.

Security Process – How to Create a Hard to Kill Process

One approach could be to use PID namespaces:

Boot your system with a init=/some/cmd as kernel parameter, where /some/cmd forks a process in a new namespace (CLONE_NEWPID) and runs /sbin/init in it (it will have PID 1 in that new namespace and pid 2 in the root namespace), then in the parent, execute your "program".

You'll probably want a way to control your program in one way or another (TCP or ABSTRACT Unix socket for instance).

You'll probably want to mlock your program in memory and close most references to the filesystem so that it doesn't rely on anything.

That process won't be seen from the rest of the system. The rest of the system will in effect run like in a container.

If that process dies, the kernel will panic which gives you an extra guarantee.

An inconvenient side-effect though is that we won't see the kernel threads in the output of ps.

As a proof of concept (using this trick to boot a copy of your system in a qemu virtual machine):

Create a /tmp/init like:

#! /bin/sh -
echo Starting
/usr/local/bin/unshare -fmp -- sh -c '
  umount /proc
  mount -nt proc p /proc
  exec bash <&2' &
ifconfig lo 127.1/8
exec socat tcp-listen:1234,fork,reuseaddr system:"ps -efH; echo still running"

(you need unshare from a recent version of util-linux (2.14)). Above we're using socat as the "program" which just answers on TCP connections on port 1234 with the output of ps -efH.

Then boot your VM as:

kvm -kernel /boot/vmlinuz-$(uname -r) -initrd /boot/initrd.img-$(uname -r) \
    -m 1024 -fsdev local,id=r,path=/,security_model=none \
    -device virtio-9p-pci,fsdev=r,mount_tag=r -nographic -append \
    'root=r rootfstype=9p rootflags=trans=virtio console=ttyS0 init=/tmp/init rw'

Then, we see:

Begin: Running /scripts/init-bottom ... done.
Starting
[...]
root@(none):/# ps -efH
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 14:24 ?        00:00:00 bash
root         4     1  0 14:24 ?        00:00:00   ps -efH
root@(none):/# telnet localhost 1234
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
UID        PID  PPID  C STIME TTY          TIME CMD
root         2     0  0 14:24 ?        00:00:00 [kthreadd]
root         3     2  0 14:24 ?        00:00:00   [ksoftirqd/0]
[...]
root         1     0  2 14:24 ?        00:00:00 socat tcp-listen:1234,fork,reuseaddr system:ps -efH; echo still running
root       204     1  0 14:24 ?        00:00:00   /usr/local/bin/unshare -fmp -- sh -c    umount /proc   mount -nt proc p /proc   exec bash <&2
root       206   204  0 14:24 ?        00:00:00     bash
root       212   206  0 14:25 ?        00:00:00       telnet localhost 1234
root       213     1  0 14:25 ?        00:00:00   socat tcp-listen:1234,fork,reuseaddr system:ps -efH; echo still running
root       214   213  0 14:25 ?        00:00:00     socat tcp-listen:1234,fork,reuseaddr system:ps -efH; echo still running
root       215   214  0 14:25 ?        00:00:00       sh -c ps -efH; echo still running
root       216   215  0 14:25 ?        00:00:00         ps -efH
still running
Connection closed by foreign host.
root@(none):/# QEMU: Terminated

Best Answer

Related Solutions

Process – How to Kill Both Process and Subprocess

Security Process – How to Create a Hard to Kill Process

Related Question