Having a really strange problem.
Scenario: PHP5.2.9, IIS7, PHP running as FastCGI. I have a site at test.concentratedtech.com. Click login, enter OpenID credentials, hit "Verify," and immediate 500 error.
Click Back, resubmit the page, works fine.
An IIS failed request trace reveals two messages, below. These messages seems to generally indicate that all is well, which is apparently enough to trigger an error. WTF.
Any ideas whatsoever? As I say, if you hit back and resubmit, it works perfectly - and you can consistently repeat that experience: Every even-numbered attempt works fine, odd-numbered attempts fail with a 500.
ONE:
ModuleName FastCgiModule
Data1 FASTCGI_RESPONSE_ERROR
Data2 Successfully fetched 'http://concentrateddon.myopenid.com/': GET response code 200
ErrorCode 5
ErrorCode Access is denied. (0x5)
TWO:
ModuleName FastCgiModule
Notification 128
HttpStatus 500
HttpReason Internal Server Error
HttpSubStatus 0
ErrorCode 0
ConfigExceptionInfo
Notification EXECUTE_REQUEST_HANDLER
ErrorCode The operation completed successfully. (0x0
Well... I'm a little incredulous but I've been randomly making changes and testing after each one.
I turned PHP's error display to off (normal production setting, but this machine is still in test so errors were being displayed). The problem went away.
I'm surmising that the 200 ("OK") response was somehow being logged as an "error" by the Yadis OpenID library. With an error to display, PHP tossed a 500. With error display off, PHP just sucks it up and keeps going. I guess.
UPDATE: Actually, the trick is the error must have SOMEWHERE to go. I disabled error display and enabled error LOGGING (e.g., to the Windows app event log, but could also be to a file), and all's well.
Related
I have set up a new Symfony3 project locally, but when I'm getting something wrong in my code the error is not displayed, only
The server returned a "500 Internal Server Error"
Is any other setting is required to display the exact error message on page?
Try to call app_dev.php instead of app.php, so in your web browser enter the yourdomain.dev/app_dev.php instead of yourdomain.dev.
A 500 error could be caused earlier in the request lifecycle than your application code, so it may not be possible to report further information "on page" depending on what service is failing. Those services may have their own settings for further error reporting in the response body; however, logs are typically the best place to look for services outside of the application code.
Turning on error reporting for your application as well, which, as #miikes suggested, in a standard symfony app can be done by using /app_dev.php instead of /app.php, could potentially provide more information if the error is in your application code.
Read your server service logs (e.g. tail -f /var/log/nginx/error.log) because 500 can be triggered by error on each level of your architecture (low on the server side or high in the app).
If you have errors in the application, very helpful would be set debug=true to the AppKernel (so you can just launch your application via app_dev.php instead of default app.php).
I have a J2.5site set up that uses language. Thus the urls look something like this:
https://www.mysite.com/en/
and
https://www.mysite.com/en/my-component/
and
https://www.mysite.com/en/my-component/my-alias
I have also set up a script that emails me whenever a 404 or 500 etc occurs:
Here is the result of one (of hundreds):
500 - Error: 500
Invalid controller: name='index', format=''
Call stack
Function Location
1 JSite->dispatch() /opt/host/apps/joomla/htdocs/index.php:42
2 JError::raiseError() /opt/host/apps/joomla/htdocs/includes/application.php:208
3 JError::raise() /opt/host/apps/joomla/htdocs/libraries/joomla/error/error.php:251
URL:/en/index.php
Notice the request. If I understand correctly, nothing should ever ask for /en/index.php. since by that time, it has already been interpreted by the entry index.php and therefore appends '/en/'
I am not getting any request errors in my apache logs or any other apache errors.
All that is happening is that I am being bombarded with emails stating that something tried to access http://www.mysite.com/en/index.php or https://www.mysite.com/en/my-component/index.php and thus either generated a 404 or 500 error
Is this spider (search engine bot) issues or is it a server misconfiguration?
Thanks
Jacques
I have a web app that allows the user to upload a pdf and it will then email it to us via swiftmailer. With some pdfs, the process fails.
I can verify that it crashes the php script, yet returns no php error. There's a 500 error from the server, but normally if there's a 500 error, php has a log of what the error was.
I have also verified that it crashes at the
$mailer->send($message);
line
Oddly, only some pdfs crash it, and those same pdfs work fine on the development server with identical code.
What could be causing php to crash without an error message?
After running several tests, I found that error logging was happening some of the time, but not others. I didn't figure out why that was so, however, I tried renaming the php-errors.log file so php would start with a new, fresh log file, and now errors are getting logged properly. I don't know why that worked, but I'll take it.
FYI, I've run into two things that can cause a PHP crash without an error message:
Script timeouts - A timeout may prevent an error message from being returned; in my particular case the script was waiting for an SMTP response when the timeout happened, which may have been why I didn't get a timeout message. Try changing your max_execution_time value in php.ini to 300 (5 minutes) and see if you can get an actual error message.
Folder permissions - I've encountered a case where insufficient folder permissions resulted in the script just halting without providing an error.
In the case of 2, I wrapped a try/catch clause around the line that was causing the halt, and I finally got an Exception to show up explaining about the permissions problem. That may be worth trying as a general response to silent crashes.
I came across an issue today, that my PHP script would send a server error 500 upon finishing (on apache). The code was something like:
//many stuff here that work
echo "It reached here";
exit;
and I was always reaching the point before the exit; command. Doing a google search, I came across this post, which suggested turning on display_errors. I did it and the 500 error went away.
So I wanted to ask, does anyone have an explanation on why this happens? This SO post describes a similar case, but there are no explanations.
As always, thanks in advance
It's pretty likely you get a 500 status code as well, but because PHP echoes something to the browser apache won't jump in and display it's standard status 500 error page.
You would need to verify the actual status code to verify that you won't still get a 500 error.
In case of a fatal error, PHP normally sends a 500 status code. As often the process has failed at that time (hence causing the fatal) and sometime no output is generated since then, the webserver jumps in and gives the user the standard 500-internal-server-error-page.
It appears that the code generated a parse error inside an eval() function in a loop. This kind of error does not break code execution but does produce a 500 error
I am using the Codeigniter framework in a project - I have a tool which reads an array and sends out over 10,000 emails using the SwiftMailer Email framework.
One form which I have once submitted is supposed to send out each individual email, however it doesnt sent out all of them as after a period of time I get the following error:
404 Page Not FoundThe page you requested was not found. - 500.shtml
The page itself doesnt actually redirect anywhere else so cannot understand why it would be saying this - anyone have any ideas?
Thanks
It looks like you're actually ending up with a 500 error, but when CI tries to display the custom error page for a 500 error (500.shtml), it can't find it, and so throws a 404 instead. Check your logs for the cause of the 500 error.
It'll be a custom error page, probably set up on the web server itself. If it's an Apache server, check the httpd config and remove any ErrorDocument directives you don't want so you can see the actual error.
As Tom said, if this is happening after a significant delay, you're likely getting a timeout. The length of timeouts can be increased from the PHP end using set_time_limit() or the php.ini setting max_execution_time. However in general if you have a long-running task it is much better to run it in a background process than try to shoehorn it into an HTTP request.