[suPHP] suPHP Zombies

[Max Korzhanoff]

    But simple idea is that without suPHP there's no zombie processes in 
our environment - there was no zombies in our old php4 installation 
before suphp and there's no zombies in our new php5 installation on 
sites that configured without suPHP. Conclusion - use of suPHP make php 
zombie processes. I think it's simple as that.
    Thanks for process explanation, but unfortunately it's too 
complicated for me to trace this error - it's not worth time (days? :)) 
I will spent on that.
    Looking forward any new updates on this subject.

Jeremy Chadwick wrote:
> The parent process in your case is httpd, which means that Apache (or a
> related Apache module) is not calling wait() when waiting for a child to
> finish.
>
> So, there is a possibility suPHP is responsible for this.  The way it
> works, without going into suphp.conf semantics:
>
>   1) httpd loads mod_suphp.so
>   2) mod_suphp.so executes /usr/local/bin/suphp
>   3) /usr/local/bin/suphp executes /usr/local/bin/php-cgi
>   4) /usr/local/bin/php-cgi parses PHP script and outputs data to
>   stdout, which makes it back to httpd.
>
> Here's the problem: there's not going an easy way to trace this down,
> because Apache makes debugging children it forks off fairly difficult.
> The problem could be in any of 3 places.
>
> truss and strace are useful utilities for tracking stuff like this down,
> but you more or less have to use them as wrapper programs, and they're
> only somewhat helpful when it comes to tracking down zombies.  They're
> better for figuring out what syscalls are being called repetitively.
>
> The even bigger problem: Apache and PHP both have a history of resulting
> in zombie processes, or behaving erroneously with fork()'d children.
> You can use Google to see said track record, otherwise look here for the
> word "child":
>
> http://www.apache.org/dist/httpd/CHANGES_2.0
>
> All I'm saying is, it could be suPHP's fault/problem, but then again it
> may not be.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mk.vcf
Type: text/x-vcard
Size: 253 bytes
Desc: not available
Url : http://lists.marsching.com/pipermail/suphp/attachments/20080506/05b7620e/attachment.vcf 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3225 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.marsching.com/pipermail/suphp/attachments/20080506/05b7620e/attachment.bin