i wrote a little shell script that kills(or tries to) all processes that
are marked with <defunct> . It just get the ppid and try to kill it if
it is not pid 1.
Do i need to use `ps axjww` for listing the processes, to not loose the
<defunct> in lines with long process names.
Or is the <defunct> state always printed in the line even if i use `ps
ajx` and it is a long process name
Thanks
Mathias
--
If you are good, you will be assigned all the work. If you are real
good, you will get out of it.
> On Wed, 09 Nov 2005 08:30:06 +0100, Mathias Pippel
> <math...@cnntp.org> wrote:
> > hi,
> >
> > i wrote a little shell script that kills(or tries to) all processes that
> > are marked with <defunct> . It just get the ppid and try to kill it if
> > it is not pid 1.
> >
> > Do i need to use `ps axjww` for listing the processes, to not loose the
> ><defunct> in lines with long process names.
> > Or is the <defunct> state always printed in the line even if i use `ps
> > ajx` and it is a long process name
> >
> It doesn't matter, you can't kill a defunct process because it's already
> dead.
He said he's killing the *parent* process. The zombie will then be
adopted by init, which will reap it.
The answer to the OP's question is that the process name will always be
printed as <defunct>, in place of the original process name. So you
don't need the ww option.
Alternatively, you could check for the state being Z (for zombie).
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
Is this right? or is defunct and zombie exactly the same?
Thanks for answers so far.
i will pass my little script so you can see what i does, btw it is
working as cron job right now, on one of our servers.
#! /bin/sh
#
#script um parents von zombieprozessen <defunct> zu killen
#es werde alle parents bis auf init (pid 1) gekillt
pslist=`ps axjww` # ps erst in variable schreiben, damit die ppid von
# awk nich mitausgeben werden kann
for i in `echo "$pslist" | awk ' ($0 ~ /<defunct>/) { print $1 ; }' \
| uniq` ; do
if [ $i -ne 1 ] ; then
kill $i
sleep 5
pgrep -P $i 1>/dev/null && kill -9 $i
fi
done
When coded correctly there is a very short time when it can
make sense to be defunct.
> Theoretically a process gets defunct when he quits and parent
> isnt catching up his return code with SIGCHLD.
If the parent forks the child, does some processing then waits
for the child there is a valid race condition.
If the parent forks the child, and never issues a wait that is a
programming bug.
> And he will turn into a zombie when his parent dies.
If the parent forks the child, issues a wait, and the child remains
as a zombie with a listed parent PID of 1, then it's an OS bug.
These bugs get rarer as time goes on.
> Is this right? or is defunct and zombie exactly the same?
Depends on your definition. To me:
Defunct equals <defunct> PPID != 1, parent has not waited, application
bug.
Zombie equals <defunct> PPID == 1, OS bug.
> #! /bin/sh
> #
> #script um parents von zombieprozessen <defunct> zu killen
> #es werde alle parents bis auf init (pid 1) gekillt
>
> pslist=`ps axjww` # ps erst in variable schreiben, damit die ppid von
> # awk nich mitausgeben werden kann
>
> for i in `echo "$pslist" | awk ' ($0 ~ /<defunct>/) { print $1 ; }' \
> | uniq` ; do
> if [ $i -ne 1 ] ; then
> kill $i
> sleep 5
> pgrep -P $i 1>/dev/null && kill -9 $i
> fi
> done
That should kill what I call defunct processes.
If possible, fix the bug in the application that is creating the
defunct
processes. The processes killed should follow a pattern.
> Barry Margolin wrote:
> > In article <22da43-...@don.localnet>,
> > Bill Marcum <bma...@iglou.com> wrote:
> >
> >
> >>On Wed, 09 Nov 2005 08:30:06 +0100, Mathias Pippel
> >> <math...@cnntp.org> wrote:
> >>
> >>>hi,
> >>>
> >>>i wrote a little shell script that kills(or tries to) all processes that
> >>>are marked with <defunct> . It just get the ppid and try to kill it if
> >>>it is not pid 1.
> >>>
> >>>Do i need to use `ps axjww` for listing the processes, to not loose the
> >>><defunct> in lines with long process names.
> >>>Or is the <defunct> state always printed in the line even if i use `ps
> >>>ajx` and it is a long process name
> >>>
> >>
> >>It doesn't matter, you can't kill a defunct process because it's already
> >>dead.
> >
> >
> > He said he's killing the *parent* process. The zombie will then be
> > adopted by init, which will reap it.
> >
> > The answer to the OP's question is that the process name will always be
> > printed as <defunct>, in place of the original process name. So you
> > don't need the ww option.
> >
> > Alternatively, you could check for the state being Z (for zombie).
> >
> Is it sure, that every <defunct> process is a zombie?
Yes, <defunct> is what ps always puts in the command field of a zombie
process. When a process exits, the OS forgets what its original command
line was, and this is the placeholder for that.
> I tried to find this out but i am not really sure about this.
> In reality i never saw a <defunct> without being a zombie.
> Theoretically a process gets defunct when he quits and parent
> isnt catching up his return code with SIGCHLD.
> And he will turn into a zombie when his parent dies.
No. When his parent dies, he will be adopted by init, which should
quickly wait() for him and he'll go away.
Barring OS bugs, there's a miniscule chance that you could catch the
process during the period between its PPID changing to 1 and being
reaped. As long as your script avoids killing PID 1, you're OK.
Nope. It's pretty likely, though. To be certain, the process state should
be 'Z'.
>I tried to find this out but i am not really sure about this.
>In reality i never saw a <defunct> without being a zombie.
It's possible that some insane or malicious developer explicitly sets the
name of a process to "<defunct>". I say they deserve what they get, but they
could trick you into killing your shell (the parent of the process).
--
Mark Rafn da...@dagon.net <http://www.dagon.net/>
They would need root access to change the name of someone else's
process. If you've got a malicious superuser, this is the least of your
worries.
No, they just need to control the name of their own. If their code
does something like
perl -e '$0 = "foobar"; sleep(600);'
you'll get a process named "<defunct>", and if you try to kill the
parent, it might be one of your processes.
> If you've got a malicious superuser, this is the least of your
> worries.
I once had a boss (with the root password) who decided it would be a
good idea to create a user named "crontab", and who thought that you
could disable an account by prepending a # to the username in
/etc/passwd. As the quip goes, any sufficiently advanced stupidity is
indistinguishable from malice.
--
Oh to have a lodge in some vast wilderness. Where rumors of oppression
and deceit, of unsuccessful and successful wars may never reach me
anymore.
-- William Cowper
> Barry Margolin <bar...@alum.mit.edu> wrote:
> > They would need root access to change the name of someone else's
> > process.
>
> No, they just need to control the name of their own. If their code
> does something like
> perl -e '$0 = "foobar"; sleep(600);'
> you'll get a process named "<defunct>", and if you try to kill the
> parent, it might be one of your processes.
I think you meant '$0 = "<defunct>"'
But I didn't realize that you were talking about someone else running
the program written by this malicious programmer, I thought you were
saying that the malicious programmer could do something to kill some
arbitrary user's shell.