[SunRescue] Killing Processes [Was: Rescue digest, Vol 1 #776 - 13 msgs]

[Mike Hebel]

Ahah!  Caught you you little bugger!

    root  3668   883  0                   0:00 <defunct>
    root  2196   883  0   Nov 02 ?       58:14 lmx.srv -s 4
    root 10463   883  0                   6:09 <defunct>
    root  2164   883  0                   0:00 <defunct>
    root   883     1  0   Nov 01 ?        0:30 lmx.ctrl
    root  4399   883  0                   0:00 <defunct>

My Lexmark software is on the fritz.  Hmm...guess I know who I'll be calling
tomorrow. ;-)

I thank you wholeheartedly!

Sincerely,

Mike Hebel

-----Original Message-----
From: rescue-admin at sunhelp.org [mailto:rescue-admin at sunhelp.org]On
Behalf Of Ed Pate
Sent: Wednesday, December 06, 2000 1:49 PM
To: rescue at sunhelp.org
Subject: Re: RE: [SunRescue] Killing Processes [Was: Rescue digest, Vol
1 #776 - 13 msgs]


Here I go again...

>
> --__--__--
>
> Message: 9
> From: "Mike Hebel" <drone8of9 at crosswinds.net>
> To: <rescue at sunhelp.org>
> Subject: RE: [SunRescue] Killing Processes [Was: Rescue digest, Vol 1
#773 - 16 msgs]
> Date: Wed, 6 Dec 2000 10:38:37 -0600
> Reply-To: rescue at sunhelp.org
>
> Actually no flames are necessary from me.  You've just explained to me why
I
> can't remove a passal of Zombie processes from our server here at work.
Now
> I just have to find out what's not responding that keeps the Zombies from
> shutting down.  Thanks!
>
> Mike Hebel
>

Actually zombies (processes marked "<defunct>") are only entries in the
process table.  They have
completely exited and all resources (except the process table entry) have
been released.  They are only
waiting on one thing, the parent process to read their return code.  Once
the parent process reads that
status OR it exits, its zombies will be cleared up.

Looks like you have some deadbeat process spawning child processes and
ignoring them.  Look at the
process table entry for the Parent Process ID (the third column of the
`ps -ef` command's output) for
these processes.  That is your culprit process.

Ed

>
> -----Original Message-----
> From: rescue-admin at sunhelp.org [mailto:rescue-admin at sunhelp.org]On
> Behalf Of Ed Pate
> Sent: Wednesday, December 06, 2000 10:26 AM
> To: rescue at sunhelp.org
> Subject: [SunRescue] Killing Processes [Was: Rescue digest, Vol 1 #773 -
> 16 msgs]
>
> > -- __--__--
> >
> > Message: 7
> > From: "Eric Ozrelic" <erico at bendcable.com>
> > To: <rescue at sunhelp.org>
> > Date: Tue, 5 Dec 2000 01:23:42 -0800
> > Organization: BendCable Communications Inc.
> > Subject: [SunRescue] Killing Processes
> > Reply-To: rescue at sunhelp.org
> >
> > I know I can use "kill <pid>" to kill a process, but how do I absolutly
> > destroy a process, when kill doesn't work?
> >
> > Regards,
> >
> > Eric Ozrelic
> >
> > -- __--__--
>
> You can use kill to send any signal to a process.  "kill <pid>" sends
signal
> 15 which
> tells the process to "settle its affairs" and then kill itself.  As many
> have replied,
> you can use "kill -9 <pid>" to send a signal 9 which tells the process to
> kill itself
> immediately, don't close any files, don't flush buffers, don't do anything
> except die.
> The only time this will not work is if the process is "wait"ing on
hardware
> or some
> kernel routine that hasn't (or will never) respond, such as a dead
harddrive
> or an NFS
> request to a remote server that is down.  The process never wakes back up
to
> process the
> signal.  There are only two ways to get rid of it then, 1) reboot, and 2)
> twiddle with
> kernel data structures.  I whole heartedly recommend the first option.
>
> Alright, alright, I know I over-explain.  Flames are welcome OFF-LIST.
>
> Ed
>
> --__--__--