The drive fail thing might be the culprit. I was poking around trying to figure out what was going on, and I tried to access my 60Gig drive - the one eDonkey was writing to at the time it died. No access. Just whirrrr....clunk. Hard drives aren't supposed to clunk... Sigh. That's the one with all my movies and TV series on it that I haven't got around to burning to disk. I rebooted to Windows and was able to read the suspect drive, but cannot complete a scandisk. Back in Linux now... Now for the next challenge... rescuing the data. C. On Saturday 03 August 2002 15:22, Dmitry Melekhov wrote:

zentara wrote:

...

On Sat, 3 Aug 2002 13:05:14 +0200

Clayton Cornell wrote:

...

So... how do you kill a process that is ignoring your attempts at a kill -9 ??

Typing kill-9 1626 seems to work - ie no errors back at the command line, but if I check with ps -e they are still there.

Just to try it, I su'ed to root and tried killing the process... same results. No erros reported, just the immortal process the refuses to be killed.

Any ideas or suggestions?

Those are zombie processes, those are children of some parent process which you already killed off. They don't respond because they are already dead, so you don't need to worry about them, they use no memory. Parents are supposed to wait for children to die before they exit, if they don't, the children become zombies, like "ghost processes". They can only be removed by a reboot.

This can be not only zombie :-( Such type of process can appear in case of i/o problems. For instance, I had this problem when I had tape drive failed- Linux think that /dev/st0 is busy with process, but /dev/st0 simply does not responded. I can reset drive, but only way to return it to Linux is reboot. The same problem is with smbfs :-(((

fuser -k /<filename> On Saturday 03 August 2002 09:31, zentara wrote:

On Sat, 3 Aug 2002 13:05:14 +0200

Clayton Cornell wrote:

...

So... how do you kill a process that is ignoring your attempts at a kill -9 ??

...

Any ideas or suggestions?

Here is something I came across.

Find the pid of the zombie, then "ps -l zombiepid" , this will show the parent pid of the zombie, then kill -9 parentpid

Works on some zombies.

On Monday 05 August 2002 09:24, Derek Fountain wrote:

A process which doesn't respond to a SIGKILL isn't a zombie. A zombie is a process which has had its parent die before it has, which means it hangs around waiting to be reaped.

That's not completely true. A zombie process is a process that has exited but its parent hasn't called wait() to get the exit status and clean up after it (the things a parent must do, eh :). Since the process has exited it won't respond to SIGKILL, it's already dead.

A process which doesn't respond to SIGKILL is one which has got stuck in the kernel - normally in a driver somewhere. If it ever returns the signal will be delivered and it will die immediately. If it's stuck because the hardware has failed, or there's a bug in the driver or something, it'll probably never come back. Rebooting is the only way out in this case.

Usually right, except in some cases I've run across you can get out of it by performing some action that causes the hardware to reset itself. For example, I once had a process that hung hard while doing a scan. It was hanging inside a scsi call and wouldn't respond to any signals. Physically resetting the scanner cleaned things up though. You're not usually this lucky, though, and as you say a reboot is usually necessary. regards Anders -- `When I use a word,' Humpty Dumpty said in rather a scornful tone, `it means just what I choose it to mean -- neither more nor less.'

On Monday 05 August 2002 09:50, Derek Fountain wrote:

We can always rely [...]

Usually :)

On Monday 05 August 2002 13:58, zentara wrote:

While Anders is interested in this thread:

:)

Is it possible someway to go right into /proc/$pid and somehow delete $pid? Is there someway of echoing a command in there to do it? I've always found the "rebooting is the only solution" pretty unsatisfactory. Maybe in future kernels?

I think it's possible to remove processes that are hanging in the way Derek described, if you have the premptible kernel patch. With that patch, even kernel processes can be interrupted by user space signals, and so it should be possible to kill them (I haven't actually tested this, but that is my understanding of things). I don't know when the preemptible patch will be in the main source tree, but until that happens you can always patch it yourself. Maybe someone at SuSE has a version of the patch that's been tested against the SuSE default kernel, I don't know. If you find out, please let me know. I've been thinking about testing that patch for a while. You can't remove things from the /proc tree in the way you can remove regular files. /proc/$pid isn't a file, it's an entry in the kernel process table. To the best of my knowledge you can only remove it by killing the process (and subsequently cleaning up the process entry, otherwise it'll be a zombie). //Anders -- `When I use a word,' Humpty Dumpty said in rather a scornful tone, `it means just what I choose it to mean -- neither more nor less.'