[suPHP] suPHP Zombies

[Dan Mahoney, System Admin]

On Tue, 6 May 2008, 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.

Why not?

Three (kinda) words for you.  mod_log_forensic.  Available in every apache 
since 1.3.30

Basically, writes to a logfile whenever a process request *starts* and 
when it *ends*.  Comes with a script to grep the log for lines that don't 
have an end.  Includes the request url.

http://httpd.apache.org/docs/1.3/mod/mod_log_forensic.html

See if this helps you.  It may not, as somehow apache may write the 
logfile line and assume the suPHP child successfully returned (but I don't 
*think* so, because apache includes things in logs like how many seconds 
it took to serve a request).

-Dan


>
> 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.
>
> --
> | 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 |
>
> On Tue, May 06, 2008 at 03:03:31PM +0300, Max Korzhanoff wrote:
>> As I wrote before, we had the same behavior with few PHP4 releases and now
>> few PHP5 releases behave the same. And here's the output with ppid.
>>
>> # ps ax -o pid,ppid,fname,wchan,comm| grep -i php-cgi
>> 5740  3705 php-cgi  exit   php-cgi <defunct>
>> 5749 26239 php-cgi  exit   php-cgi <defunct>
>> 5751  5689 php-cgi  -      php-cgi
>> 5752 28375 php-cgi  -      php-cgi
>> 5753 28419 php-cgi  -      php-cgi
>>
>> # ps auxwww | grep 3705
>> apache    3705  2.0  3.5 287988 150268 ?     S    14:56   0:01
>> /usr/sbin/httpd
>> root      5831  0.0  0.0  1660  516 pts/1    S+   14:58   0:00 grep 3705
>>
>> Any more thoughts on that?
>>
>> Jeremy Chadwick wrote:
>>> I can confirm this behaviour, although I'm not so sure the problem is
>>> related to suPHP.  I'd have to look at the code to see if wait() or
>>> waitpid() is being called in the parent when fork() is used.
>>>
>>> I'm more inclined to believe the problem is with PHP itself, possibly
>>> when called as a CGI.  I see some Google results which confirm this.
>>>
>>> In the case of real-life scenarios: we have a couple users who use web
>>> board scripts which do retarded things, and most of those scripts result
>>> in defunct (zombie) processes.  However, those processes automatically
>>> get reaped when they exit.  I have not seen them "stick around", except
>>> for the very early days when we used FreeBSD 4.x and very old PHP.
>>>
>>> Your below ps does not include parent PIDs, which would be useful,
>>> although the parent process may be httpd (which won't tell much).
>>>
>
>> begin:vcard
>> fn:Max Korzhanoff
>> n:Korzhanoff;Max
>> org:GARM Technologies
>> adr:;;Ozolciema 46/3-44;Riga;Latvia;LV-1058;Latvia
>> email;internet:mk at garmtech.lv
>> title:CEO
>> tel;cell:+371 26402104
>> x-mozilla-html:TRUE
>> url:http://www.garmtech.lv
>> version:2.1
>> end:vcard
>>
>
>
>
>
>> _______________________________________________
>> suPHP mailing list
>> suPHP at lists.marsching.biz
>> http://lists.marsching.com/mailman/listinfo/suphp
>
>
> _______________________________________________
> suPHP mailing list
> suPHP at lists.marsching.biz
> http://lists.marsching.com/mailman/listinfo/suphp
>

--

"I love you forever eternally."

-Connaian Expression

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org
---------------------------