Re: killed process still on-screen
On Sat, 19 Jan 2002 12:37:26 -0800
"Eric G. Miller" <egm2@jps.net> wrote:
> On Sat, 19 Jan 2002 13:52:25 -0500, dman <dsh8290@rit.edu> wrote:
>
> > On Sat, Jan 19, 2002 at 08:15:49AM +0800, csj wrote:
> > | On Thu, 17 Jan 2002 19:42:40 -0600
> > | Nori Heikkinen <nori@sccs.swarthmore.edu> wrote:
> > |
> > | > on Thu, 17 Jan 2002 11:33:25PM +0200, Ian Balchin insinuated:
[...]
> > | How do I terminate the living dead?
> > |
> > | alpha:~# ps -A | grep defunct
> > | 31080 ? 00:00:00 gpg <defunct>
> > | 31081 ? 00:00:00 gpg <defunct>
> > | alpha:~# kill -9 31080
> > | alpha:~# ps -A | grep defunct
> > | 31080 ? 00:00:00 gpg <defunct>
> > | 31081 ? 00:00:00 gpg <defunct>
> > |
> > | And here's top's top:
> > |
> > | 08:11:45 up 5 days, 17:10, 6 users, load average: 0.07, 0.03, 0.00
> > | 94 processes: 91 sleeping, 1 running, 2 zombie, 0 stopped
> >
> > 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.
Yep, I'm using Sylpheed. Are you a mind reader or did you just read my
X-Mailer line? And your diagnosis in this instance is probably correct.
I lost the zombies when I did a ps after stopping X. But my question is
more hypothetical than practical.
To sum up this discussion: zombies can be killed, but only if you know
their mothers. Is this correct? Kill the parent process and the zombies
go away?
Reply to: