[ale] Boot script becomes a zombie?

[Brandon Checketts]

Conceptually, you should be able to send a SIGCHLD signal to the parent process
to tell it to clean up (ie: call wait()) after its children.  In reality, I have
no idea if that actually works.

kill -15 {parent PID}

Thanks,
Brandon Checketts



Lightner, Jeff wrote:
> In that situation sometimes (though not always) killing the parent will
> get rid of the zombie.
> 
> As an HP presenter used to say at the start of his performance
> presentations:
> You can't kill a zombie because IT'S ALREADY DEAD!
> 
> -----Original Message-----
> From: ale-bounces at ale.org [mailto:ale-bounces at ale.org] On Behalf Of
> Michael H. Warfield
> Sent: Monday, February 22, 2010 2:29 PM
> To: Atlanta Linux Enthusiasts - Yes! We run Linux!
> Cc: mhw at wittsend.com
> Subject: Re: [ale] Boot script becomes a zombie?
> 
> On Sun, 2010-02-21 at 23:05 -0500, James Sumners wrote: 
>> I have a script that looks runs several other scripts in turn. I use
>> this script to startup several FastCGI processes. This is the script:
> 
>> ##########
>> #!/bin/bash
>> find /var/www/fastcgi/scripts/ -type f -execdir '{}' 2>&1 1>/dev/null
> \;
>> return $?
>> ##########
> 
>> I then have the following crontab entry for root:
>> @reboot /path/to/boot_cgi_bin.sh
> 
>> Every time I reboot my server, this boot_cgi_bin.sh script turns into
>> a zombie (the cgi bins do get started). Does anyone see a reason why
>> this script would hang up as a zombie process?
> 
> A zombie process means that process terminated but the process (which
> would seem to be cron in this case) which started it has not reaped the
> child's status.  It's really all gone and only exists as an entry in the
> proc table.  This CAN happen if a child it invokes leaves it's file
> descriptors open and they're pipes back to the parent (it's what causes
> ssh to refuse to terminate after running a script which restarts
> services.).  I had to deal with that in the smbmount program when I was
> maintaining it.
> 
> Do a ps -lp {process id} on that process id and then see what the parent
> process is (may be a shell).
> 
> Might also redirect stdin from /dev/null just in case one of those
> scripts you're invoking is doing something funny with stdin.
> 
> Mike