mjhjmtu

Sometime process exists and cannot be killed due to:

• being zombie. I.e. process which parent did not read the exit status. Such process does not consume any resources except PID entry. In top it is signaled Z


• erroneous uninterruptible sleep. It should not happen but with a combination of buggy kernel code and/or buggy hardware it sometime does. The only method is to reboot or wait. In top it is signaled by D.

It sounds like you might have a zombie process. This is harmless: the only resource a zombie process consumes is an entry in the process table. It will go away when the parent process dies or reacts to the death of its child.

You can see if the process is a zombie by using top or the following command:

ps aux | awk '$8=="Z" print $2'

Check your /var/log/kern.log and /var/log/dmesg (or equivalents) for any clues. In my experience this has happened to me only when an NFS mount's network connection has suddenly dropped or a device driver crashed. Could happen if a hard drive crashes as well, I believe.

You can use lsof to see what device files the process has open.

If @Maciej's and @Gilles's answer's don't solve your problem, and you don't recognize the process (and asking what it is with your distro doesn't turn up answers ). Check for Rootkit's and any other signs that you've been owned. A rootkit is more than capable of preventing you from killing the process. In fact many are capable of preventing you from seeing them. But if they forget to modify 1 small program they might be spotted ( e.g. they modified top, but not htop ). Most likely this is not the case but better safe than sorry.

Kill actually means send a signal. there are multiple signals you can send. kill -9 is a special signal.

When sending a signal the application deals with it. if not the kernel deals with it. so you can trap a signal in your application.

But I said kill -9 was special. It is special in that the application doesn't get it. it goes straight to the kernel which then truly kills the application at the first possible opportunity. in other words kills it dead

kill -15 sends the signal SIGTERM which stands for SIGNAL TERMINATE in other words tells the application to quit. This is the friendly way to tell an application it is time to shutdown. but if the application is not responding kill -9 will kill it.

if kill -9 doesn't work it probably means your kernel is out of whack. a reboot is in order. I can't recall that ever happening.

First, check if its a Zombie process (which is very possible):

ps -Al

You will see something like:

0 Z 1000 24589 1 0 80 0 - 0 exit ? 00:00:00 soffice.bin <defunct>

(Note the "Z" on the left)

If the 5th column is not 1, then it means it has a parent process.
Try killing that parent process id.

If its PPID = 1, DON'T KILL IT!!, think which other devices or processes may be related to it.

For example, if you were using a mounted device or samba, try to unmount it. That may release the Zombie process.

As others have mentioned, a process in uninterruptible sleep cannot be killed immediately (or, in some cases, at all). It's worth noting that another process state, TASK_KILLABLE, was added to solve this problem in certain scenarios, particularly the common case where the process is waiting on NFS. See http://lwn.net/Articles/288056/

Unfortunately I don't believe this is used anywhere in the kernel but NFS.

The init process is immune to SIGKILL.

This is also true also for kernel threads, i.e. "processes" with a PPID equal to 0.

Made a little script that helped me a lot take a look!

You can use it to kill any process with a given name in its path(pay attention to this!!)
Or you can kill any process of a given user using the "-u username" parameter.

#!/bin/bash

if [ "$1" == "-u" ] ; thenn
 PID=`grep "$2" /etc/passwd | cut -d ":" -f3`
 processes=`ps aux | grep "$PID" | egrep -v "PID|ps -au|killbyname|grep" | awk ' print $2'`
 echo "############# Killing all processes of user: $2 ############################"
else
 echo "############# Killing processes by name: $1 ############################"
 processes=`ps aux | grep "$1" | egrep -v "killbyname|grep" | awk ' print $2' `
fi


for process in $processes ; do
 # "command" stores the entire commandline of the process that will be killed
 #it may be useful to show it but in some cases it is counter-productive
 #command=`ps aux | grep $process | egrep -v "grep" | awk ' print $2 '`
 echo "Killing process: $process"
 echo ""
 kill -9 $process
done

There are cases where even if you send a kill -9 to a process, that pid will stop, but the process restarts automatically (for instance, if you try it with gnome-panel, it will restart): could that be the case here?

from here originally:

check if strace shows anything

strace -p <PID>

try attaching to the process with gdb

gdb <path to binary> <PID>

if the process was interacting with a device that you can unmount, remove the kernel module for, or physically disconnect/unplug... then try that.

I had kind of this issue. This was a program that I had launched with strace and interrupted with Ctrl+C. It ended up in a T (traced or stopped) state. I don't know how it happened exactly, but it was not killable with SIGKILL.

Long story short, I succeeded in killing it with gdb:

gdb -p <PID>
> kill
Kill the program being debugged? (y or n) y
> quit