Been running WordPress on PHP 5.3.5 for some time now but recently the system has developed a terminal problem. Every few loads I'll get a 500 error - maybe 6 to 10 page refreshes. There's no logging, no problems, and the page returns to normal on the
next refresh. Both my load balanced servers have the same problem on 2 WordPress separate sites each.
Machine is Windows 2008R2 (so IIS7.5).
I have tried for 10 hours to find the problem with no success.
Failed Request Tracing identifies: FastCgiModule / ExecuteRequestHandler / PHP53_via_FastCGI
The error code is: 0x00000000 (helpful)
I switched from using an Application Pool Identity to a named account, but no joy.
Occasionally I correlate the crash with the spawning of a new php-cgi.exe process, but not always. To make it crash I just sit on the home page and hit 'refresh' a few times - normally takes less than a minute to crash it.
When it works, it's very fast. Then every so often it'll just hang for about 20 seconds, then go bang. Then happily continue on its way. Nothing in "php-errors", nothing in the Event Log, nothing.
I can't recall any server changes and I'm hesitant to blame code since 4/5 page loads work properly. I tried installing a newer version of PHP (5.3.10) but that had no effect so, in the interests of science I rolled it back. I have two effectively identical
servers and I've only been playing with one so I have, in essence, a control group - not that it's helping.
I've read 1,000,000 posts on this topic and fettled 128.4 PHP.INI settings to no avail...
Help.
fastcgi modulephp-cgi.exe500 - Internal server erroriis7.5
It sounds like a bug in the FastCGI-error handler. What are your php.ini settings for display_errors, log_errors and fastcgi.logging? Try chaning the following php.ini settings display_errors (to On), log_errors (to Off) and fastcgi.logging (to 0). Assuming
you've followed an installation and configuration guide like http://learn.iis.net/page.aspx/724/install-and-configure-php/. If you configure an user_ini.filename, you can overrule these settings on a per-directory basis. See php.ini comments for more information
about this. Let me know if this solved your problem.
From the posts that I read the fastcgi.logging controls whether 'informational' messages are sent from the CGI'd process back through the FastCGI layer, which it incorrectly interperets as an error. Not sure how accurate my understanding is there - that
seems a bit lame. Why wouldn't you just check the result code? Anyways...
The other settings, I believe, are consistent with the 'production' configuration. Though no logging is generated whatsoever.
I tried with your suggested settings (and also set display_startup_errors = on) but it has not changed the result, nor has it resulted in any logs being written anywhere.
[While I didn't follow that precise page's instructions I did follow some very similar. Thing is it has been working for AGES - more than a year!]
I noted that there are pending Windows Updates so I'm going to install them and bounce the machine and see if that helps any - definitely clutching at straws now. :(
**EDIT I can now reproduce this issue on 2 machines, with 4 different customised WordPress installs, and one completely vanilla WordPress install simply by refreshing teh home page of the respective site repeatedly a dozen times or so.
Still waiting for the updates to complete. Then will update PHP also. Can't update WordPress itself but I'm highly sceptical that WordPress is at fault here.
**EDIT2 WordPress, as a potential culprit, is back on the table. I took the simple session counting script from the Install Link you provided and created a test.php on the site, then successfully refreshed it 500 times without crashing FastCGI or w3wp or
getting a 500 error back. I'm using WordPress 3.0.1 but I'm surprised that even vanilla against the default dummy post it crashes out. I'm not a PHP programmer so I can't do the script but my next stop would be a simple MySQL call to see if MySQL is involved
somehow. Any help there?
Just in case someone's following along. I fixed it. Whew.
Turns out the connections to MySql were timing out intermittently because ports on the DB server were all stuck in TIME_WAIT due to an unrelated Windows bug. I noticed that a pure PHP page ran just fine, but once i added a really simple 1-row DB call it
was crashing out. That exonerated WordPress again but put the blame squarely at MySql's feet. Much poking on the DB server and I noticed there was 45,000+ network connections in TIME_WAIT so I started closing firewall ports and they never went away... are
we starting to see a problem now?
Had to fettle the registry to fix that but it explains the intermittent works/doesn't work thing nicely.
Still can't believe there was no error message anywhere to say "Database connection timed out". That's painful. I'm just going to wire WordPress to MSSQL next time.
Marked as answer by Lloydz on May 01, 2012 10:22 AM
I'm seeing exactly the same thing -- TIME_WAITs on the MySQL ports and all. What did you do in the registry to make MySQL happy. Have you test MSSQL with WordPress multisite? I found it to be a little flakey, but that was about year ago.
richardhauer...
3 Posts
Intermittent 500 error with PHP 5.3.5
Apr 23, 2012 11:23 AM|LINK
Been running WordPress on PHP 5.3.5 for some time now but recently the system has developed a terminal problem. Every few loads I'll get a 500 error - maybe 6 to 10 page refreshes. There's no logging, no problems, and the page returns to normal on the next refresh. Both my load balanced servers have the same problem on 2 WordPress separate sites each.
Machine is Windows 2008R2 (so IIS7.5).
I have tried for 10 hours to find the problem with no success.
Failed Request Tracing identifies: FastCgiModule / ExecuteRequestHandler / PHP53_via_FastCGI
The error code is: 0x00000000 (helpful)
I switched from using an Application Pool Identity to a named account, but no joy.
Occasionally I correlate the crash with the spawning of a new php-cgi.exe process, but not always. To make it crash I just sit on the home page and hit 'refresh' a few times - normally takes less than a minute to crash it.
When it works, it's very fast. Then every so often it'll just hang for about 20 seconds, then go bang. Then happily continue on its way. Nothing in "php-errors", nothing in the Event Log, nothing.
I can't recall any server changes and I'm hesitant to blame code since 4/5 page loads work properly. I tried installing a newer version of PHP (5.3.10) but that had no effect so, in the interests of science I rolled it back. I have two effectively identical servers and I've only been playing with one so I have, in essence, a control group - not that it's helping.
I've read 1,000,000 posts on this topic and fettled 128.4 PHP.INI settings to no avail...
Help.
fastcgi module php-cgi.exe 500 - Internal server error iis7.5
JanReilink
36 Posts
Re: Intermittent 500 error with PHP 5.3.5
Apr 23, 2012 12:38 PM|LINK
Vevida Services - worry-free webhosting: http://vevida.com
richardhauer...
3 Posts
Re: Intermittent 500 error with PHP 5.3.5
Apr 25, 2012 11:32 AM|LINK
At present my settings are:
From the posts that I read the fastcgi.logging controls whether 'informational' messages are sent from the CGI'd process back through the FastCGI layer, which it incorrectly interperets as an error. Not sure how accurate my understanding is there - that seems a bit lame. Why wouldn't you just check the result code? Anyways...
The other settings, I believe, are consistent with the 'production' configuration. Though no logging is generated whatsoever.
I tried with your suggested settings (and also set display_startup_errors = on) but it has not changed the result, nor has it resulted in any logs being written anywhere.
[While I didn't follow that precise page's instructions I did follow some very similar. Thing is it has been working for AGES - more than a year!]
I noted that there are pending Windows Updates so I'm going to install them and bounce the machine and see if that helps any - definitely clutching at straws now. :(
**EDIT I can now reproduce this issue on 2 machines, with 4 different customised WordPress installs, and one completely vanilla WordPress install simply by refreshing teh home page of the respective site repeatedly a dozen times or so. Still waiting for the updates to complete. Then will update PHP also. Can't update WordPress itself but I'm highly sceptical that WordPress is at fault here.
**EDIT2 WordPress, as a potential culprit, is back on the table. I took the simple session counting script from the Install Link you provided and created a test.php on the site, then successfully refreshed it 500 times without crashing FastCGI or w3wp or getting a 500 error back. I'm using WordPress 3.0.1 but I'm surprised that even vanilla against the default dummy post it crashes out. I'm not a PHP programmer so I can't do the script but my next stop would be a simple MySQL call to see if MySQL is involved somehow. Any help there?
richardhauer...
3 Posts
Re: Intermittent 500 error with PHP 5.3.5
Apr 25, 2012 04:40 PM|LINK
Just in case someone's following along. I fixed it. Whew.
Turns out the connections to MySql were timing out intermittently because ports on the DB server were all stuck in TIME_WAIT due to an unrelated Windows bug. I noticed that a pure PHP page ran just fine, but once i added a really simple 1-row DB call it was crashing out. That exonerated WordPress again but put the blame squarely at MySql's feet. Much poking on the DB server and I noticed there was 45,000+ network connections in TIME_WAIT so I started closing firewall ports and they never went away... are we starting to see a problem now?
Had to fettle the registry to fix that but it explains the intermittent works/doesn't work thing nicely.
Still can't believe there was no error message anywhere to say "Database connection timed out". That's painful. I'm just going to wire WordPress to MSSQL next time.
robsiii
1 Post
Re: Intermittent 500 error with PHP 5.3.5
May 03, 2012 02:38 PM|LINK
quichwrigley
1 Post
Re: Intermittent 500 error with PHP 5.3.5
Nov 06, 2012 05:50 PM|LINK
Hi Richard,
What did you do in your registry to fix this problem? I get this error occasionally, but usually when I try to edit the permalinks page in wordpress.
Thanks,
Rich