ID:               38757
 User updated by:  davidb at pins dot net
 Reported By:      davidb at pins dot net
 Status:           Open
 Bug Type:         Apache related
 Operating System: Solaris 8
 PHP Version:      5.1.6
 Assigned To:      dmitry
 New Comment:

A few other quick comments:

-  Perl + CGI::Fast hasn't reported any of these problems
-  This is only affecting a small subset of users, but those users tend
to continue to have the problems recur
-  The users with recurring problems will sometimes suddenly, and
without warning, start working again

I strongly suspect some odd network interaction, but I'm not entirely
sure where to dig deeper just yet.

The FastCGI PHP instance is linked as a local UNIX socket:

  FastCgiServer /export/httpd/DOMAINS/host.forward.com/cgi-bin/php
-port 9050
  AddHandler php-fastcgi .php
  <Location /cgi-bin/php>
    SetHandler fastcgi-script
  </Location>
  Action php-fastcgi /cgi-bin/php

There are several other vhosts that use teh FastCgiExternalServer
directive.  We are using the PHP process manager to front-end the PHP
work threads by setting PHP_FCGI_CHILDREN.


Previous Comments:
------------------------------------------------------------------------

[2006-09-12 15:50:36] davidb at pins dot net

Greetings.

Is the poll() timing out, even though it appeared to get all of the
data in fd4?  Or, is there additional data that isn't getting passed on
for some reason?  I can send the entire truss if you'd like.

We're running Apache 1.3.33, Solaris 8, on a dual-processor SPARC.  I
believe it's the 2.4.2 FastCGI.  I do note that the read() that a valid
post gets is different.

In a good truss:

poll(0xFFBED8F0, 1, 1000)                       = 1
read(4, "0101\001\0\b\0\0", 8)                  = 8
read(4, "\001\0\0\0\0\0\0", 8)                  = 8
read(4, "0104\001\015\0\0", 8)                  = 8
read(4, 0xFFBDD918, 21)                         = 21
  0E05 C O N T E N T _ L E N G T H 6 1 0 1 5
read(4, "0104\001\0 V\0\0", 8)                  = 8
read(4, 0xFFBDD918, 86)                         = 86
  \f H C O N T E N T _ T Y P E m u l t i p a r t / f o r m - d a t
   a ;   b o u n d a r y = - - - - - - - - - - - - - - - - - - - -
   - - - - - - - 1 9 1 9 4 1 1 2 6 6 2 0 5 9 7
read(4, "0104\001\0 =\0\0", 8)                  = 8
read(4, 0xFFBDD918, 61)                         = 61
  \r . D O C U M E N T _ R O O T / e x p o r t / h t t p d / D O M
   A I N S / t e s t 2 . f o r w a r d . c o m / h t d o c s

The poll seems to return with a 1, but the data that's read in is the
same.  Is there something about the submit from different users that
would cause the poll() to return differently?  I have network snoops,
as well.

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

[2006-09-11 07:55:00] [EMAIL PROTECTED]

>From the strace log I see: PHP FastCGI server accepts connection and
waits 1 sec (in pool()) for any input from HTTP client. It doesn't get
any data in a second and does save connection close.

Could you describe your environment: CPU speed, WebServer, fastcgi
plugin, fastcgi configuraion...


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

[2006-09-09 21:09:16] [EMAIL PROTECTED]

Dmitry, could you plz check it out?

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

[2006-09-09 02:05:01] davidb at pins dot net

Well, I tried with the latest 5.2b snapshot, and now it's broken for my
PC at home also.  Appears to be the identical problem - php just
silently stops processing after it reads in the POST data, closes the
socket, and then waits for the next request, throwing a 500 server
error.

Please.

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

[2006-09-08 22:09:08] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php5.2-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php5.2-win32-latest.zip



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

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/38757

-- 
Edit this bug report at http://bugs.php.net/?id=38757&edit=1

Reply via email to