If you can be sure to read the return value (even to just discard it)
the zombies should stay in their graves.
On Sat, 2009-03-07 at 19:37 -0500, Eben King wrote:
> On Sat, 7 Mar 2009, Paul Bransford wrote:
> > On Sat, 2009-03-07 at 17:30 -0500, Paul Bransford wrote:
> >> On Sat, 2009-03-07 at 14:13 -0500, Eben King wrote:
>
> >>> How can I get rid of these?
> >>>
> >>> 4871 root 0 0 0 0 exit Z 0 0.0 0:00 aplay <defunct>
> >>> 4874 root 0 0 0 0 exit Z 0 0.0 0:00 aplay <defunct>
> ...
>
> >> http://en.wikipedia.org/wiki/Zombie_process
> >>
> >> Whatever process is calling these children needs to read their return
> >> value. These processes are harmless in that manner, each one only
> >> containing enough memory to hold process information and the return
> >> value. They should die as soon as that value is read.
>
> > Of particular note from that article:
> >
> > To remove zombies from a system, the SIGCHLD signal can be sent to the
> > parent manually, using the kill command. If the parent process still
> > refuses to reap the zombie, the next step would be to remove the parent
> > process. When a process loses its parent, init becomes its new parent.
> > Init periodically executes the wait system call to reap any zombies with
> > init as parent.
>
> Method 1: no go:
> eben@pc:~$ ps axf | grep -B 1 '[a]play'
> 18532 tty1 S 0:00 /bin/sh -e /etc/rc.local
> 18534 tty1 Z 0:00 \_ [aplay] <defunct>
> 18550 tty1 Z 0:00 \_ [aplay] <defunct>
> ...
>
> eben@pc:~$ ps axf | grep -B 1 '[a]play' | wc -l
> 28
>
> eben@pc:~$ sudo kill -SIGCHLD 18532
>
> eben@pc:~$ ps axf | grep -B 1 '[a]play' | wc -l
> 28
>
> Method 2: success:
>
> eben@pc:~$ sudo kill 18532
>
> eben@pc:~$ ps axf | grep -B 1 '[a]play'
>
> eben@pc:~$
>
> Thanks. I've changed the method they're launched, so maybe this way will
> work better.
>
-----------------------------------------------------------------------
This list is provided as an unmoderated internet service by Networked
Knowledge Systems (NKS). Views and opinions expressed in messages
posted are those of the author and do not necessarily reflect the
official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 19:10:57 EDT