# kill kill [solved]

## idella4

I have a fs which plays up somewhat.  It hanfs when something goes wrong.  It's btrfs.  It's experimental and I'm experimenting.

I'd like to know how to kill it when it hangs. O get

```

new-distfiles/Python-2.6.5.tar.bz2

^C^X^Z^Z^X^C

```

& 

```

genny karmic #  mount -t btrfs -o subvol=kernels /dev/loop0 /mnt/kernels

genny karmic # ls -l /mnt/kernels

^Z^X^C^C^X^Z

```

```

genny idella # ls /mnt/btrfs1

^Z^X^C^C

```

kill is intended to kill processes.  I tried & tried, ended up killing the bash console following the parent processes, and it was still going.

```

genny idella # ps -e 

  PID TTY          TIME CMD

    1 ?        00:00:03 init

 1172 ?        00:00:00 dhclient

 2340 ?        00:00:00 syslog-ng

 2341 ?        00:00:00 syslog-ng

 2400 ?        00:00:00 dbus-daemon

 2434 ?        00:00:00 wpa_supplicant

 2486 ?        00:00:00 kdm

 2576 tty1     00:00:00 login

 2577 tty2     00:00:00 login

 2578 tty3     00:00:00 agetty

 2579 tty4     00:00:00 agetty

 2580 tty5     00:00:00 agetty

 2581 tty6     00:00:00 agetty

 2584 tty1     00:00:00 bash

 2829 ?        00:00:00 dhclient

 4836 ?        00:01:48 tar

 4837 ?        00:20:00 bzip2 <defunct>

 8125 ?        00:00:00 udevd

 9481 ?        00:00:00 ls

10847 tty2     00:00:00 bash

10855 tty2     00:00:00 xinit

10856 tty7     00:00:27 X

10859 tty2     00:00:00 sh

10860 tty2     00:00:00 startkde

10898 tty2     00:00:00 dbus-launch

10899 ?        00:00:00 dbus-daemon

10906 tty2     00:00:00 start_kdeinit

10907 ?        00:00:00 kdeinit4

10908 ?        00:00:00 klauncher

10910 ?        00:00:00 kded4

10912 ?        00:00:00 gam_server

10917 tty2     00:00:00 kwrapper4

10918 ?        00:00:00 ksmserver

10920 ?        00:00:02 kwin

10922 ?        00:00:00 kglobalaccel

10924 ?        00:00:00 knotify4

10926 ?        00:00:05 plasma-desktop

10928 ?        00:00:01 ksysguardd

10932 ?        00:00:00 kaccess

10939 ?        00:00:00 krunner

10943 ?        00:00:00 nepomukserver

10953 ?        00:00:00 kmix

10954 ?        00:00:00 wpa_gui

10955 ?        00:00:00 okular

10957 ?        00:00:00 kget

10958 ?        00:00:00 konqueror

10959 ?        00:00:07 firefox

10962 ?        00:00:00 gconfd-2

10963 ?        00:00:02 konsole

10968 ?        00:00:00 klipper

10972 pts/2    00:00:00 bash

10975 pts/3    00:00:00 bash

10982 pts/4    00:00:00 bash

10995 ?        00:00:00 korgac

11059 pts/2    00:00:00 sudo

11060 pts/2    00:00:00 bash

11076 pts/2    00:00:00 ls

11086 pts/3    00:00:00 top

11111 ?        00:00:00 kdesud

11131 ?        00:00:00 dbus-launch

11132 ?        00:00:00 dbus-daemon

11171 pts/3    00:00:00 sudo

11172 pts/3    00:00:00 bash

11200 ttyS1    00:00:00 agetty

11201 ?        00:00:00 agetty

11202 pts/3    00:00:00 ps

15531 ?        00:00:00 dhclient

15658 ?        00:00:00 dhclient

19938 ?        00:00:00 sudo

20280 ?        00:00:00 bash

22105 ?        00:00:00 sudo

22106 ?        00:00:00 bash

22310 ?        00:00:00 man

22313 ?        00:00:00 sh

22314 ?        00:00:00 sh

22318 ?        00:00:00 less

23141 ?        00:00:00 man

23144 ?        00:00:00 sh

23145 ?        00:00:00 sh

23149 ?        00:00:00 less

genny idella # ps -e | grep bzip2

 4837 ?        00:20:00 bzip2 <defunct>

genny idella # kill -9 4837

genny idella # ps -e | grep bzip2

 4837 ?        00:20:00 bzip2 <defunct>

genny idella # 

```

In this case, the btrfs has done a hang, which ties up a console tab and prevents any access to the fs device.  It can't be unmounted.

How do you track and kill the culprit processes?  The only way now is to re-boot.

----------

## Hu

Some types of severe hang can be interrupted with a SIGKILL.  If that does not work, you will need to reboot and avoid exercising the buggy kernel code path.

----------

## idella4

Hu,

does that imply the kill should work, and that it doesn't implies a faulty kernel?  Is SIGKILL = kill

----------

## Hu

 *idella4 wrote:*   

> does that imply the kill should work, and that it doesn't implies a faulty kernel?  Is SIGKILL = kill

  *man kill wrote:*   

> The  default  signal  for  kill is TERM.

 Even if SIGKILL fails, that does not necessarily mean the kernel is faulty with regard to signal handling.  There are some situations where the process may be so utterly broken that the kernel has no way to forcibly unwind it, in which case a SIGKILL could be deferred until the program finishes the current syscall.

----------

## idella4

 *Hu wrote:*   

> 
> 
> in which case a SIGKILL could be deferred until the program finishes the current syscall.
> 
> 

 

Hmmm,  follow vaguely.  It appears like you describe, so utterly broken that the kernel has no way to forcibly unwind it.  which program is program?  Waiting until it finished on something that is hung and frozen means I can't kill it.  Does it appear that it is so utterly broken, and the reboot is the only way to kill it?  I try sending these rogue processes the kill signals within a kdesu sysguard, and they laugh it off.  I did manage to kill  a couple on the CLI that were tar processes, but that's all.

----------

## salahx

Well, its not so much "process may be so utterly broken that the kernel has no way to forcibly unwind it", rather, there  are 2 types of "sleep" in the kernel: interruptable and uninterruptible. In the top and ps utilites, interruptible sleeps are marked by "S" for "Sleep", and uninterruptible sleeps are "D" for "Disk" (the usual case for non-interruptible sleep is disk I/O). A process in a non-interruptible sleep is totally unresponsive, even to SIGKILL.

(I think around Linux 2.6.25 or so a new "killable" state was added: Its works like an uninterruptable sleep with one exception: If the process gets a "fatal" signal, its dies on the spot)

----------

## Hu

That was an editing glitch on my part.  I should have said stuck, not broken.  As salahx notes, some uninterruptible states can be broken with a SIGKILL because the kernel knows that no further user code will execute.  If the process is not reacting to a SIGKILL, then it will not react to anything until it finishes the current system call.  If the process is stuck due to a kernel bug, it may never finish the call and thus never die.

----------

## idella4

Hu,

ok, I see.  In this case, the source is the btrfs drivers, experimental and established as quite a way from stable.  I would say that would be consistent with If the process is stuck due to a kernel bug, it may never finish the call and thus never die..

So is why only an exit from the system will kill it.

----------

## dmpogo

 *idella4 wrote:*   

> Hu,
> 
> ok, I see.  In this case, the source is the btrfs drivers, experimental and established as quite a way from stable.  I would say that would be consistent with If the process is stuck due to a kernel bug, it may never finish the call and thus never die..
> 
> So is why only an exit from the system will kill it.

 

The process can be unkillable even without kernel bug.  There is even special state for that "uninterruptable sleep",  (state D as shown by top)

----------

## idella4

ok, so they were unkillable.  An attempt to invoke reboot or logout was also overthrown.  Nasties, they were.  Oh well, thanks.

----------

## Yamakuzure

Your processes are marked as "<defunct>", which means their state is "Z" aka "Zombie". in most cases you will have only one option to get rid of a zombie process: reboot. They can not be killed, they can not be stopped.

----------

## Bircoph

Yes, these are defunct processes. Usually they occur when I/O deadlock happens. In some cases this is solvable: e.g. dead nfs server will respond. You may avoid these problems by using non-blocking i/o mode. However, I do not know how to do this on btrfs.

----------

## salahx

In the case of a dead NFS server, non-blocking (via O_NONBLOCK) won't help: Under Linux O_NONBLOCK has no effect on "normal" files and directories, even those on network server like NFS or CIFS. This is by design. (Actually this flag has a lot of of other side effects as well

Zombie processes are caused by parent process who don't wait() for their children. If the parent process process died, the child is re-parented to init, which will immediately wait() and reap it.

----------

## idella4

ok. thx

----------

