Re: is killing zombies possible w/o a reboot?

From: Bill Davidsen (davidsen_at_tmr.com)
Date: 11/10/04

  • Next message: Francois Romieu: "Re: ZyXEL GN650-T" 
    Date:	Tue, 09 Nov 2004 18:31:31 -0500
To: DervishD <lkml@dervishd.net>

    DervishD wrote:
    > Hi Bill :)
    >
    > * Bill Davidsen <davidsen@tmr.com> dixit:
    >
    >>> If you are talking about others' children, then your call to
    >>>waitpid() (or wait()) failed with ECHILD: not your child.
    >>
    >>That's what happened when I tried it a few months ago. I suppose one
    >>could try sending a SIGCHLD to the parent and see if it does something
    >>helpful.
    >
    >
    > Probably it won't do. If the zombies are there due to a signal
    > delivery problem, sending a SIGCHLD to the parent will (probably)
    > solve the problem. But the common case is that the parent is screwed
    > up or simply so badly programmed that the only way of getting rid of
    > the zombies is to kill the parent...

    Wait a minute, in another message you just suggested that a SIGCHLD to
    init would cause the status to be reaped.
    >
    > Anyway I suppose that sending the SIGCHLD won't do any harm so it
    > may be worth trying.

    It won't hurt init, but some processes do use the SIGCHLD to trigger a
    wait(), which might hang the parent. 

    -- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Francois Romieu: "Re: ZyXEL GN650-T"

    Relevant Pages

    • Re: using fork and wait reliably w/signals
      ... > I don't know what the book says about signals. ... you should wait for the child. ... > the parent process will exit soon anyway, ... If the system is not POSIX compliant, then you can ignore the SIGCHLD ...
      (comp.os.linux.development.system)
    • Re: 2.6.x Fork Problem?
      ... >> or the parent set up a SIGCHLD handler before the fork. ... >> So, by the time the parent gets the CPU, the child is long gone. ... that we needed to change the signal handler for SIGCHLD. ...
      (Linux-Kernel)
    • Re: is killing zombies possible w/o a reboot?
      ... in another message you just suggested that a SIGCHLD to ... > init would cause the status to be reaped. ... 'adopts' them when the real parent doesn't care for them. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [PATCH 2/2] ptrace children revamp
      ... this adds a minor pessimization. ... pointers to parent process, youngest child, younger sibling, ... SIGCHLD, and we are doing the threaded reparenting. ... is from the same thread-group. ...
      (Linux-Kernel)
    • Re: SIGSEGV on SIGCHLD
      ... > bewildering effect that involves a parent forking, ... > process, and as soon as the child dies away, and a SIGCHLD signal is sent ... then of course looking at the handler you ... before the code that results in the SIGSEGV, ...
      (comp.unix.programmer)