Professional Web Applications Themes

<defunct> state in `ps ajx` compared to `ps axjww` - Linux / Unix Administration

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

  1. #1

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

    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
    Mathias Guest

  2. #2

    Default Re: <defunct> state in `ps ajx` compared to `ps axjww`

    On Wed, 09 Nov 2005 08:30:06 +0100, Mathias Pippel
    <org> wrote: 
    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.
    Bill Guest

  3. #3

    Default Re: <defunct> state in `ps ajx` compared to `ps axjww`

    In article <localnet>,
    Bill Mar <com> wrote:
     
    > It doesn't matter, you can't kill a defunct process because it's already
    > dead.[/ref]

    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, mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    Barry Guest

  4. #4

    Default Re: <defunct> state in `ps ajx` compared to `ps axjww`

    Barry Margolin wrote: 
    >>
    >>It doesn't matter, you can't kill a defunct process because it's already
    >>dead.[/ref]
    >
    >
    > 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).
    >[/ref]
    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
    Mathias Guest

  5. #5

    Default Re: <defunct> state in `ps ajx` compared to `ps axjww`

    Mathias Pippel wrote: 

    When coded correctly there is a very short time when it can
    make sense to be defunct.
     

    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.
     

    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.
     

    Depends on your definition. To me:

    Defunct equals <defunct> PPID != 1, parent has not waited, application
    bug.
    Zombie equals <defunct> PPID == 1, OS bug.
     

    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.

    Doug Guest

  6. #6

    Default Re: <defunct> state in `ps ajx` compared to `ps axjww`

    In article <4372e9e0$0$12099$cnntp.org>,
    Mathias Pippel <org> wrote:
     
    > >
    > >
    > > 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).
    > >[/ref]
    > Is it sure, that every <defunct> process is a zombie?[/ref]

    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.
     

    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.

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

  7. #7

    Default Re: <defunct> state in `ps ajx` compared to `ps axjww`

    Mathias Pippel <org> wrote: 

    Nope. It's pretty likely, though. To be certain, the process state should
    be 'Z'.
     

    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 net <http://www.dagon.net/>
    Mark Guest

  8. #8

    Default Re: <defunct> state in `ps ajx` compared to `ps axjww`

    In article <dagon.net>,
    net (Mark Rafn) wrote:
     
    >
    > Nope. It's pretty likely, though. To be certain, the process state should
    > be 'Z'.

    >
    > 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).[/ref]

    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.

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

  9. #9

    Default Re: <defunct> state in `ps ajx` compared to `ps axjww`

    Barry Margolin <mit.edu> wrote: 

    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 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
    Jeremiah Guest

  10. #10

    Default Re: <defunct> state in `ps ajx` compared to `ps axjww`

    In article <dlav2d$2tg$panix.com>,
    Jeremiah DeWitt Weiner <com> wrote:
     
    >
    > 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.[/ref]

    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.

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

Similar Threads

  1. FMS Core crash(defunct)
    By Ryan463 in forum Macromedia Flash Flashcom
    Replies: 2
    Last Post: September 10th, 09:49 AM
  2. Bindings Panel Defunct
    By juane in forum Dreamweaver AppDev
    Replies: 8
    Last Post: August 20th, 03:15 PM
  3. Defunct processes
    By Alvaro in forum UNIX Programming
    Replies: 3
    Last Post: October 1st, 02:17 PM
  4. Hung/rogue/defunct/ processes
    By snogfest hosebeast in forum AIX
    Replies: 0
    Last Post: July 28th, 02:01 AM

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139