On Tue, May 06, 2008 at 04:11:29PM +0300, Max Korzhanoff wrote: > 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.
And your previous environment involved the use of PHP as an Apache module, right? Where the PHP code ran natively within Apache, since mod_php[45].so were being loaded and executed by Apache? In that environment, fork() is not used to spawn a PHP CGI interpreter per request. That environment is *completely* different than with suPHP. Zombie processes can happen any time in a UNIX environment where the parent process does not call wait() after forking the child. Kill the parent process (in your case, Apache) and the zombie will disappear, because the zombie'd child will then have a PPID of 1 (which is init), and init will reap zombie children. Zombie processes happening isn't a good thing, but an occasional zombie (which then gets reaped a second or two later) is acceptable. Your situation is troubling because the zombie processes aren't being reaped -- ever. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | > > 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 > _______________________________________________ suPHP mailing list suPHP@lists.marsching.biz http://lists.marsching.com/mailman/listinfo/suphp
