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.
begin:vcard fn:Max Korzhanoff n:Korzhanoff;Max org:GARM Technologies adr:;;Ozolciema 46/3-44;Riga;Latvia;LV-1058;Latvia email;internet:[EMAIL PROTECTED] title:CEO tel;cell:+371 26402104 x-mozilla-html:TRUE url:http://www.garmtech.lv version:2.1 end:vcard
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ suPHP mailing list suPHP@lists.marsching.biz http://lists.marsching.com/mailman/listinfo/suphp
