[suPHP] suPHP Zombies

[Kai]

Hello,

I have the same problem on one server, but I use suphp 0.6.2 on another 
server without any problem.

Server is OK:

OpenSUSE 10.2
Apache 2.0.59
PHP 4.4.7
PHP 5.2.0
suPHP 0.6.2

Server is bad:

OpenSUSE 10.3
Aapache 2.0.63
PHP 4.4.8
PHP 5.2.0
suPHP 0.6.3

Sometimes (one ore two times in 24h) there are to many zombie-prozesses of 
PHP on the bad server and the server need to be resetet by a hard reset, 
because I can't kill the prozesses.

I now will test the bad-server with a downgrade to Apache 2.0.59 and suPHP 
0.6.2. If this fails, I will downgrade to PHP 4.4.7.

Regards

Kai

----- Original Message ----- 
From: "Max Korzhanoff" <mk at garmtech.lv>
To: "Jeremy Chadwick" <suphp at jdc.parodius.com>
Cc: <suphp at lists.marsching.biz>
Sent: Tuesday, May 06, 2008 3:11 PM
Subject: Re: [suPHP] suPHP Zombies


>    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.
>


--------------------------------------------------------------------------------


> _______________________________________________
> suPHP mailing list
> suPHP at lists.marsching.biz
> http://lists.marsching.com/mailman/listinfo/suphp
>