# how to kill a process that wont die?

## Gentree

I am having a problem killing a process that has stalled.

I left aMule running and when I came back the window would not repaint and although the system menu came down, Close did nothing. Also the terminal from which I launched aMule only echos keystrokes but wont come back to the command prompt.

I used xkill to get rid of the frozen window but I still have a hung process and cant rerun aMule : it just sits at the "Initialiskng" stage .

pgrep amule gets me a PID but killall amule or kill -9 pid fails to get rid of the hung process.

What else can I do, short of rebooting to kill this process ?

```

 7484 tty1     S      0:00 xterm

 7486 pts/1    S      0:00 bash

 7714 ?        D     51:39 amule

```

TIA. Gentree.  :Cool: 

----------

## NeddySeagoon

Gentree,

You need to kill its parent process. Look at ps -Al to check that.

Don't kill init though will you?

----------

## Gentree

Thanks , I didnot know about -Al , that's useful.

```

ls -Al

...

4 S     0  7484     1  0  80   0 -  1325 -      tty1     00:00:00 xterm

4 S     0  7486  7484  0  82   0 -   551 wait4  pts/1    00:00:00 bash

0 D  1000  7714     1  6  82   0 - 22138 lock_p ?        00:51:39 amule

```

PPID = 1 , I get the feeling I dont want to kill that, it looks important.

any idea what the lock_p is about and how I can kill it?

Thanks again.  :Cool: 

----------

## Muso

killall -9 name-of-prog

----------

## Gentree

As I stated in the original post kill -9 doesn't . That's what the post is about.

Thanks for the reply.

----------

## piffle

```
 7714 ?        D     51:39 amule 
```

"D" is the uninterruptible wait state. The process is waiting on something (usually IO) and will not awake for anything but whatever resource it is expecting. If a process is mistakenly hung in such a state, there is absolutely no way to kill it (you don't have to take my word -- you can go dig around old kernel mailing lists).  You will have to reboot to get rid of it.

----------

## Gentree

Thanks for a full and clear reply.

|I had a masty feeling this might be the case .

Does this suggest inappropriate IO from aMule or is this a process the kernel itself would have started and now cant stop?

I must say I'm a bit disappointed in the kernel here , I expected to be able to issue some command as superuser to change its parentID (or something like that) then kill it.

Thanks again.  :Cool: 

----------

## piffle

Well, there's always trade-offs right? Killing a process is a mechanical thing; presumabely they could have allowed killing these processes but the consequences outweighed any gain. Some decisions have only unpleasant alternatives.

As to why, I don't know.  I get the feeling that when it hangs like this, whatever was being waited on signaled that it was ready, but the process never got the signal somehow, and since the resource won't signal again. . . This used to always happen to me with mozilla (now that was annoying!).  I'd suggested googling for "uninteruptible sleep"+amule, etc. and filing a bug with the amule devs with as much info as possible.  If this is repeatable, for instance, you might run amule with strace or in a debugger, etc.

----------

## zaleth

I believe it has something to do with memory integrity. When a user-space program calls an IO function, it passes a buffer of user-space memory that should either be filled with data from a device or written to a device. If the process could be killed while waiting for that IO operation to complete, then theoretically the kernel funtion would attempt to access memory that has already been freed (part of killing a process is freeing all memory it has allocated), which would result in an oops. Hence processes waiting for IO can't be killed.

----------

## Gentree

Thanks for the explainations.

I agree , it's probably a trade off situation. aMule will have called a kernel routine for disk IO, this routine is not returning and that is hanging the process, so I dont think there is a problem with aMule.

I would have thought there was some way for the kernel to deal with this but as you say, it may be a negative trade-off . I feel a bit happier about the situation now.

Finally I found where the problem was coming from. It was a bit of over-tweeking in my kernel that only showed up after several hours of running aMule.

There was a responce delay for IDE devices that I had reduced from the default 50ms because the help suggested it may be too conservative now. I put it back to 50 and all seems well.

So zaleth, you were not far wrong with your guess at it being memory integrity.

I suspected it may have been my tweek , but this kill not working is a problem I have come up against in the past and I thought it was simply a lack of knowlege on my part and I simply lacked the right command.

Thanks to all for your help. At least I know clearly where I am and feel more confident about the way the kernel handles this.

 :Cool: 

----------

