Revision 8134cc27
Added by Scott Ullrich almost 16 years ago
| etc/inc/system.inc | ||
|---|---|---|
| 777 | 777 |
"socket" => "/tmp/php-fastcgi.socket", |
| 778 | 778 |
"min-procs" => 1, |
| 779 | 779 |
"max-procs" => {$max_procs},
|
| 780 |
/* This problem seems to stem from a little-known issue with PHP: |
|
| 781 |
* PHP stops accepting new FastCGI connections after handling 500 requests; |
|
| 782 |
* unfortunately, there is a potential race condition during the PHP cleanup |
|
| 783 |
* code in which PHP can be shutting down but still have the socket open, so |
|
| 784 |
* lighty can send request number 501 to PHP and have it "accepted", but then |
|
| 785 |
* PHP appears to simply exit, causing a 500 return from lighty. |
|
| 786 |
*/ |
|
| 787 |
"PHP_FCGI_MAX_REQUESTS" => "500", |
|
| 780 | 788 |
"idle-timeout" => 0, |
| 781 | 789 |
{$bin_environment}
|
| 782 | 790 |
"bin-path" => "/usr/local/bin/php" |
Also available in: Unified diff
Adding PHP_FCGI_MAX_REQUESTS => 500. This problem seems to stem from a little-known issue with PHP: PHP stops accepting new FastCGI connections after handling 500 requests; unfortunately, there is a potential race condition during the PHP cleanup code in which PHP can be shutting down but still have the socket open, so lighty can send request number 501 to PHP and have it accepted, but then PHP appears to simply exit, causing a 500 return from lighty.