4

I'm trying to track down a bug or mis-configuration on our new Debian web server running a PHP/MySQL driven website with apache. I won't bug you with the gory details here but just want to ask:

Did anyone out there ever observe the web browser receiving a "http 500 inernal server error" while NOTHING alike appears in the apache's error and access log? It's currently not about the details here, but just that I believe this strange behavior should already lead into the right direction since I don't believe there are many possibilities where this can happen at all.

When this internal server error happens, the PHP scripts continue running just fine without any failure, but of course the result they want to deliver to the browser will never appear, since the browser already thinks about his internal server error being the end of the world as he knows it.

Any comment/idea welcome,

Roman.

Roman Blöth
  • 101
  • 1
  • 1
  • 5
  • It could be appearing in the core logs. That is, all of our in house applications log to specific directories other than the root Apache log; but if something happens outside the app (say the interpreter crashes), it would get recorded to /var/log/httpd/*. Could this be the case? – Andrew M. Apr 19 '11 at 14:02
  • That's a very good idea, I will check this. – Roman Blöth Apr 19 '11 at 14:07

7 Answers7

6

SOLVED: Alas, there is a load balancer controlling the server, and the load balancer was set up to stop connections after 10 seconds of inactivity or so. The problem is solved now. The reason the 500 did not show up in the apache's error.log is that it was the "outer" system (the load balancer) stopping the connection, not the server itself. Thank you all for your ideas and help! Hopefully someone else will find this enlightening some day.

Best regards, Roman.

Roman Blöth
  • 101
  • 1
  • 1
  • 5
2

This could be an issue with your Apache LogLevel directive or it could be related to the PHP runtime error handling.

user9517
  • 114,104
  • 20
  • 206
  • 289
  • Also a nice hint, thank you. I will have a look into this tomorrow. – Roman Blöth Apr 19 '11 at 14:14
  • Ok, Apache's LogLevel is "warn", and PHP has set it's error reporting to E_ALL. But still nothing appears in the logs. There's a ghost in the line throwing 500 errors at the clients... – Roman Blöth Apr 19 '11 at 14:20
1

Other possibility : Look for @ in your source files.

Extract from php documentation

Warning
Currently the "@" error-control operator prefix will even disable error reporting for critical errors that will terminate script execution. Among other things, this means that if you use "@" to suppress errors from a certain function and either it isn't available or has been mistyped, the script will die right there with no indication as to why.

Credits go to Luc M, which saved me, and a lot of CodeIgniter users.

Community
  • 1
Balmipour
  • 294
  • 1
  • 3
  • 10
0

It will only show in the apache error log if the error is raised within the apache code - but you should still see it in the access log (with a status code of 500) if the status is set within the PHP code. Although there can be instances where the PHP processes crashes entirely (though these are very rare).

NB it can also occur when connecting via a proxy and the proxy screws up.

symcbean
  • 19,931
  • 1
  • 29
  • 49
  • It does also not appear in the access.log (sorry I did not mention this). The php processes do not crash but instead run fine in order to finish their tasks (we can see this because php fills a custom log file during it's work) while the browser already shows "internal server error". We have no idea where this can come from. – Roman Blöth Apr 19 '11 at 14:09
0

The 500 is coming from another host via something inline the document? Perhaps you've got your CSS or some such coming from another box? Also try adding an ErrorLog Directive. Use Firebug or Chrome webdev tools to find out where the 500 is coming from, could even be an ad or something in the page.

Also try something like CURL or LWP to make a request, see what the response headers are, for example:

lwp-request -m HEAD -eSsd http://www.google.com/
HEAD http://www.google.com/ --> 200 OK
Cache-Control: private, max-age=0
Connection: close
Date: Tue, 19 Apr 2011 15:56:26 GMT
Server: gws
Content-Type: text/html; charset=ISO-8859-1
Expires: -1
Client-Date: Tue, 19 Apr 2011 15:56:26 GMT
Client-Peer: 74.125.91.99:80
Client-Response-Num: 1
Client-Transfer-Encoding: chunked
Set-Cookie:
REF=ID=b4ac3801dfbd939c:FF=0:TM=1303228586:LM=1303228586:S=nU_H2eC3zcLbTKfb;
expires=Thu,18-Apr-2013 15:56:26 GMT; path=/; domain=.google.com Set-Cookie:
NID=46=dsepCUy0iW9MDD7AkaP1-P4INDfRLTXz7l_TchQFzCGqtP4GU1EFbpn7K-sKq-ujNhpnR
Br8Cqgdyd3LyC3mxsRDOCCFoOn2OutZad7VWFs5erWVh0UNgEgkQJGqRe-; expires=Wed, 19-Oct-2011
15:56:26 GMT; path=/; domain=.google.com; HttpOnly
X-XSS-Protection: 1; mode=block

edit: GF spotted a typo.

Ben Lutgens
  • 351
  • 1
  • 4
0

I had the same issue and it was caused by error reporting setting in PHP. Although I had E_ERROR | E_WARNING | E_PARSE in my .htaccess PHP did not log PHP Fatal error into error log. Only 500 in accesslog. Even half of the page was generated (until I called the function with that error).

Radek Hladík
  • 600
  • 1
  • 3
  • 14
0

For Symfony projects, don't forget to check app/logs

You can find more details on that question :
https://stackoverflow.com/questions/18577003/how-to-debug-500-error-in-symfony-2

Btw, other frameworks or CMS may have similar behaviour.

Community
  • 1
Balmipour
  • 294
  • 1
  • 3
  • 10