Re: killed process still on-screen
On Sat, 19 Jan 2002 17:44:48 -0500, dman <dsh8290@rit.edu> wrote:
> On Sat, Jan 19, 2002 at 12:37:26PM -0800, Eric G. Miller wrote:
> | On Sat, 19 Jan 2002 13:52:25 -0500, dman <dsh8290@rit.edu> wrote:
>
> | > Those processes are blocked on IO or something. Thus it is the
> | > _kernel_ itself that is stuck, which is why SIGKILL has no effect.
> | > When a process is executing in its own space, the kernel can kill it
> | > and clean up the pieces. When the process is executing inside the
> | > kernel (in a system call) then the kernel can't blow it away because
> | > it would then need to somehow put itself back together.
> |
> | I believe those are zombies of one or more forked processes. They're
> | kept around so the parent can do a waitpid() on them. Other than
> | a PID, they shouldn't be taking up any memory or other resources.
> | Sylpheed is notorious for creating gpg zombies.... They'll dissappear
> | when the parent exits.
>
> That's possible too. I thought "zombie" meant "blocked in system
> call never to return".
Not my understanding. If a "zombie" is the living dead, then a zombie
process is one that is really dead, but appears alive (shows up in
the process tree). A program blocked in a system call, might eventually
become unblocked, and then start running again. I think "blocked in
system call, never to return" is a variant on "bug". A program that
get's in such a state, probably has a design flaw (barring unusual
circumstances).
> There's some app (pstree maybe?) that shows what the parent is. If
> the parent is still around, see if killing it makes the zombies go
> away.
Yes, pstree works. Zombies should always disappear when their parent
exits. The reason they're kept around at all, is so the parent can
check the return code (and possibly do something depending on its
value).
--
Eric G. Miller <egm2@jps.net>
Reply to: