Re: is killing zombies possible w/o a reboot?

[Valdis . Kletnieks]

On Wed, 03 Nov 2004 13:53:39 EST, Gene Heskett said:
> On Wednesday 03 November 2004 12:44, DervishD wrote:

> >    Then the children are reparented to 'init' and 'init' gets rid
> > of them. That's the way UNIX behaves.
> 
> Unforch, I've *never* had it work that way.  Any dead process I've 
> ever had while running linux has only been disposable by a reboot.

The problem  likely isn't the true "zombie" - the only thing that *those*
processes have left is a process table entry to save the exit code for a wait()
syscall that might not happen anytime soon.  And unless you have hundreds
of them sitting around causing pressure on the 32K process limit, they're
probably not a big problem.

More likely, what you're looking at is some process that has gone down into the
kernel on some syscall or other and gotten blocked.  Since signals aren't
delivered until it returns, it ends up "unkillable".

Traditionally, a common cause for such wedging was a lost/misplaced interrupt
from an I/O operation, so a read()/write()/ioctl() call wouldn't return because
the device hadn't reported it completed. (tape drives were notorious for this).
Often, power-cycling the I/O device would cause an unsolicited interrupt to be
generated, which would clear the "waiting for interrupt" issue and allow the
process to return....

Attachment: pgp00000.pgp
Description: PGP signature