Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

<defunct> state in `ps ajx` compared to `ps axjww`

34 views
Skip to first unread message

Mathias Pippel

unread,
Nov 9, 2005, 2:30:06 AM11/9/05
to
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

Thanks

Mathias

Bill Marcum

unread,
Nov 9, 2005, 6:24:18 PM11/9/05
to
It doesn't matter, you can't kill a defunct process because it's already
dead.


--
If you are good, you will be assigned all the work. If you are real
good, you will get out of it.

Barry Margolin

unread,
Nov 10, 2005, 1:20:11 AM11/10/05
to
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).

--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

Mathias Pippel

unread,
Nov 10, 2005, 1:33:57 AM11/10/05
to
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?
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.

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

Doug Freyburger

unread,
Nov 10, 2005, 1:58:10 PM11/10/05
to
Mathias Pippel wrote:
>
> Is it sure, that every <defunct> process is a zombie?
> 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.

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

unread,
Nov 10, 2005, 8:26:18 PM11/10/05
to
In article <4372e9e0$0$12099$6e1e...@read.cnntp.org>,
Mathias Pippel <math...@cnntp.org> wrote:

> 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.

Mark Rafn

unread,
Nov 11, 2005, 2:44:07 PM11/11/05
to
Mathias Pippel <math...@cnntp.org> wrote:
>Is it sure, that every <defunct> process is a zombie?

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/>

Barry Margolin

unread,
Nov 12, 2005, 11:29:58 AM11/12/05
to
In article <7t8f43-...@hydra.dagon.net>,
da...@dagon.net (Mark Rafn) wrote:

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.

Jeremiah DeWitt Weiner

unread,
Nov 14, 2005, 4:20:13 PM11/14/05
to
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.


> 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

unread,
Nov 14, 2005, 8:48:51 PM11/14/05
to
In article <dlav2d$2tg$1...@reader2.panix.com>,

Jeremiah DeWitt Weiner <j...@panix.com> wrote:

> 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.

0 new messages