php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #71551 scripts not run from php-cgi with mod_fcgid
Submitted: 2016-02-09 01:37 UTC Modified: 2016-03-18 14:05 UTC
Votes:2
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:2 (100.0%)
From: ian at ocucom dot com Assigned: ab (profile)
Status: Closed Package: Apache2 related
PHP Version: 7.0.3 OS: Windows 7
Private report: No CVE-ID: None
View Developer Edit
 [2016-02-09 01:37 UTC] ian at ocucom dot com 
Description:
------------
When using mod_fcgid with php-cgi to handle scripts, intermittently, php-cgi.exe will start, but the script will not seem to load (no error_log() statements are logged, no output is sent, cpu usage is 0%) and after the fcgid timeouts, apache reports mod_fcgid: read timeout from pipe. 

This behavior is intermittent but seems to be related to new instances of php-cgi.

Apache: Apache Lounge 2.4.18 Win32 x86
Mod_fcgid: Apache Lounge mod_fcgid 2.3.9 Win32 x86
PHP: Windows.php.net PHP 7.0.3 php-cgi.exe



Expected result:
----------------
php runs a .php script

Actual result:
--------------
no content is returned, fcgid script timeout is reached, apache reports read timeout, serves 500 error. 

Happens more frequently if FcgidMaxRequestsPerProcess is set to 1. FcgidConnectTimeout values seem to have no effect. It appears that mod_fcgid never "hooks up" to the php-cgi process.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2016-02-09 01:41 UTC] ian at ocucom dot com 
Also, thread-safe vs non-thread safe makes no difference. This error has occurred in every version of 7.0 since RC2. It does not occur, using the same configs, with PHP 5.6.5.
 [2016-02-09 20:51 UTC] ian at ocucom dot com 
This also occurs using the Win32/x64 builds of Apache, mod_fcgid and php of the same point releases.
 [2016-02-16 20:31 UTC] ab@php.net
-Status: Open +Status: Feedback
 [2016-02-16 20:31 UTC] ab@php.net 
Please pastebin your Apache and PHP configs somewhere. If no one came to it, i'm going to check when having a time frame. Will be useful otherwise anyway.

Thanks.
 [2016-02-17 21:53 UTC] ian at ocucom dot com 
Here's a gist of the config files and a sample index.php to show the error:

https://gist.github.com/IanAtOcucom/0137d6c5f0cb70cdd51e
 [2016-02-28 04:22 UTC] php-bugs at lists dot php dot net 
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.
 [2016-02-28 04:41 UTC] requinix@php.net
-Status: No Feedback +Status: Open
 [2016-02-28 17:34 UTC] ian at ocucom dot com 
If comments aren't feedback, then what am I doing wrong. So, again:

Here's a gist of the config files and a sample index.php to show the error:

https://gist.github.com/IanAtOcucom/0137d6c5f0cb70cdd51e
 [2016-02-29 20:19 UTC] ian at ocucom dot com 
Here's a gist of the config files and a sample index.php to show the error:

https://gist.github.com/IanAtOcucom/0137d6c5f0cb70cdd51e
 [2016-02-29 20:19 UTC] ian at ocucom dot com 
Here's a gist of the config files and a sample index.php to show the error:

https://gist.github.com/IanAtOcucom/0137d6c5f0cb70cdd51e
 [2016-02-29 20:41 UTC] requinix@php.net 
It's alright @ian, we got it. The "no feedback" thing was done by a bot that looks at the ticket status, not whether someone made a reply.
 [2016-03-18 14:05 UTC] ab@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: ab
 [2016-03-18 14:05 UTC] ab@php.net 
@ian thanks for the additional information. I've just fetched the latest builds from apachelounge.com and setup mod_fcgid using your configs. Currently I see no issue, neither with the script you've supplied nor with anything else. It seems to function correctly. From this i have a conclusion, that you have some configuration issue. By checking the config files, i see nothing extraordinary bad in them (not counting small things like soap.wsdl_cache_dir="/tmp").

Still, you should recheck your paths, that the dirs are writable, that there are no php installations preceeding the %path%, no other servers share the same port, other ini settings, etc. I'm closing this for now, feel free to reopen if you have a stable reproducer.

Thanks.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sun Feb 16 01:01:29 2025 UTC