I am struggling with Symfony 2 error reporting because I can't find out what really is happing when a 500 Error is triggered.
I have XDebug correctly installed, but it seems like Symfony rules everything.
The custom pages just says:
Oops! An Error Occurred
The server returned a "500 Internal Server Error".
Something is broken. Please e-mail us at [email] and let us know what you were doing when this error occurred. We will fix it as soon as possible. Sorry for any inconvenience caused.
That's pretty much funny! Something is broken, but, the fact is that I need to fix my code, but can't know what or where it is the problem! And sure, If I send an email for the Symfony team will they be able to solve my problem once I not even know what to say them?
Some clue on what I am missing here?
For Symfony 2 and below,
First, look at the logs in app/logs depending on your environment — dev.log for development, prod.log for production, etc.
If the code crashes before Symfony has a chance to run, check the logs of your web server — e.g. nginx.
If you have a symfony flex project, it is also possible that you forgot to install monolog ;) Run:
composer req log
For Symfony versions 3.x, 4.x, 5.x, 6.x and above,
The logs will be found depending on the environment
For dev env - var/logs/dev.log
For prod env- var/logs/prod.log
Also, as the accepted answer suggests, you might have to check the server logs if your app crashes before even reaching Symfony.
Usual location for server logs is listed below -
For apache server - ls /var/log/apache2
For Nginx server - ls /var/log/nginx
sudo chmod -R o+w var/cache/
from inside the project's folder,
solved the problem for me, at least this time :)
There were no errors in Symfony's or web server's logs.
What caused the problem
It turned out that the problem was caused by me previously removing the cache folder, and regenerating the cache, i.e.
rm -fr var/cache/
./bin/console cache:clear
After that, var/cache became drwxr-xr-x.
An even better way to improve your Symfony debugging process is to have Monit monitor your Symfony and Apache logs for any errors and send you emails whenever something bad happens: http://intelligentbee.com/blog/2016/01/12/how-to-monitor-symfony-and-apache-logs-with-mmonit/
Related
Any time I select an admin option i get the below error.
Error: Class 'Drupal\Core\Form\FormErrorHandler' not found in Drupal\Component\DependencyInjection\Container->createService() (line 258 of core\lib\Drupal\Component\DependencyInjection\Container.php).
I have cleared my cache and restarted wamp, not sure what the next step is.
If I get an error that is in a core or contributed module and clearing cache and and server restart doesn't help, I usually try running database updates next to see if any where missed.
Have you run the update.php? if that fails you could try using drush to run the update.php using drush updb
If that doesn't work I would run a backup of the codebase and db then try updating the modules, then update core using drush drush up
Restarted my PC and that seemed to work. I have no idea what the error is linked to, but that seems to work if anyone is having the same issue.
my Symfony 3 app works flawless on my local webserver. Since it´s been installed on the remote web server it produces a blank page, even the routing doesn't work. After editing web/app.php $kernel = new AppKernel('prod', false); and set it to true, the application works as expected and does not display any errors.
Why does the application behave different on the local and the remote webserver. Did I miss to configure something on the remote server?
Any suggestions?
Thanks in advance!
Finally I have a solution to solve the problem: after the composer update I have to clear the cache of the prod environment manually by executing rm -fr var/cache/prod/*. For whatever reason does the command php bin/console cache:clear --env=prod quit working immediately after the composer update without throwing any error messages. After removing the cache files manually both the application and the cache:clear command work as expected without modifying web/app.php.
1.check permission to cache and log dirs ( need to be 777 )
2.check (paste here) error in logs/prod.log
Since I couldn´t find out what´s the real cause of this problem I´ve made a fresh install of my application and updated Symfony and all dependencies with composer.
Although I did the same with the old installation, it does the trick this time. My guess is, something went wrong with the composer update before.
Thanks again for your help! If someone has a similar problem I would appreciate if you could post how you solved the problem (or why AppKernel['prod'] = 'true' did work).
I have plausible explanation, what might have been the problem.
I have encountered this problem earlier this year with Symfony3, while developing on Windows but deploying manually (copying project's files) to shared server with Linux.
As you say - blank page in prod environment.
To add to the mystery log files did not show any problems
So i enabled dev environment to check what is wrong
application worked as intended if i added app_dev.php in the URL
I overviewed all the files, more than once, but copy was done correctly.
The answer
After some time I "came across" the file: bootstrap.php.cache in var directory. It "felt suspicious".
As I had exhausted my options i just deleted it to test the result.
That solved it in my case.
Site was running again.
No more blank page!
I guess mixed development environment has its toll.
I keep getting an error with the MonologBundle for Symfony2:
Monolog\Logger::DEBUGS in /foo/vendor/symfony/monolog-bundle/Symfony/Bundle/MonologBundle/DependencyInjection/MonologExtension.php on line 119
It only happens in prod and happens only once, right after deleting the cache. After a refresh everything is back to normal.
All other answers suggest updating composer, which I have done, or deleting the bundle and monolog and reinstalling, which I have also done.
It happens both on my local machine (mac) and during deployment to my ubuntu machine using capistrano 2.x with capifony. Composer is freshly downloaded during those deploys, so composer version probably isn't the issue here.
Does anyone know how to solve this? Thanks in advance!
Most likely you have a typo in config, where you defined a log level for one of your handlers as "debugs" instead of "debug". Check your config.
I have a website with NGINX & PHP-FPM. A few hours ago I checked my website and NGINX throw an error. My website was down.
I check the status pages of NGINX and the fpm pool, and the fpm status page did not load.
Then I checked the status of PHP-FPM with "service php5-fpm status" and it showed that it wasn't running. So I restarted it.
Right now everything is fine, and commonly nothing wrong happens, but now I want to know what could possibly turn off php-fpm? Could it be a script? A memory problem? Is it a common practice to have a script controlling that PHP-FPM is running?
Thanks you!
Who knows, this is why us sysadmins install monitoring solutions and 24hour text notifications, and install things like puppet and template it to ensure certain services are always running... You'll get a more detailed answer on www.serverfault.com - this is a programming site.
Probably a segmentation fault in a php child. Do your php-fpm logs show segmentation faults or other errors?
Yes, it's common practice to have a service running that checks to make sure php-fpm and other services are running.
I am using Apache Solr for one of my Drupal sites. I start my Apache Solr with Java -Jar -Xmx256M start.jar to fix the memory limit. I run my Apache in screen, but at times i see that my instance of Apache solr gets stopped/killed automatically. In my dev server i find it very hard to start it manually. Is there any fix to stop the instance getting killed automatically?
By the way the following are some of the warning i get in the console
"solrconfig.xml: is deprecated and no longer recommended used."
"WARNING: and configuration sections are deprecated (but still work). Please use instead."
Thanks.
I had this problem initially as well. I solved it by starting a screen session as root and starting Solr within that session. Also try adding a nohup before the java command and see if that works.