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.
Related
When I do symfony self-update I get the following error - how can I solve it?
Backup failed, rename D:\SERVER\Symfony\symfony.exe C:\Users\FairyWilbury\.symfo
ny\autoupdate\2019-07-19_14-57-14-79024bb-old: The system cannot move the file t
o a different disk drive.. Canceling upgrade.
UPD.
I have just realized that the latest symfony version seems to be 4.3 with 4.4 due to release in November https://symfony.com/roadmap/4.4
Yet whenever I run symfony new --full %projectName% it suggests I should update to 4.6 (and then fails to update as described above). Screenshot of the command line: What can this problem be?
First of all, you're mixing up Symfony Local Web Server and the Symfony PHP framework. You can use the web server, which is a single executable command line developer tool, to start a new Symfony-based project or start a local server that makes your web application available for testing and debugging while you develop it. The framework, on the other hand, is the code base you build web application on.
When you run
symfony self-update
from the command line, you (try to) update the web server, not the framework.
The latest version of the web server, at the time of writing, is 4.12.10, while the framework is at 5.0.5 (or 4.4.5), so, as you can see, they're completely independent from each other.
Back to the original problem, and I was struggling with this as well, the catch is that we both use Windows and installed the web server (symfony.exe) to a folder in drive D: (in your case it's D:\SERVER\Symfony). While it's running, it stores config and other files in a ".symfony" directory in the folder of your Windows user account (C:\Users\FairyWilbury). And during the self-update process, that's where it tries to move the original symfony.exe file. For some unknown reason, it cannot do that between different drives, not even in an Administrator-privileged command line window.
Strange, as it is, the only solution I found was the following.
I created a TEMP folder on drive C:
Copied symfony.exe from its folder on drive D: to C:\TEMP
Opened up command line, and switched the current dir to C:\TEMP
Ran symfony self-update -- this time it went smoothly
Closed the command line window
Moved the new symfony.exe file from C:\TEMP to the folder on drive D:
Removed C:\TEMP folder
I know it's a bit cumbersome, but we have to consider that Windows is not the most popular development platform for PHP applications. ;)
okay, look, in this case, I dont really find anything about this symfony self-update stuff, so...
In the version title the third part (so the 1 in 4.6.1) is a patch, what that only contains bug fixes, so you need the latest minor version first 4.6.0.
Basicly you need follow this doc:
symfony/doc/upgrade_patch.html
And, as it starts above, first you need follow this doc (attentively):
symfony/doc/4.2/upgrade_minor.html
This upgrade_minor.html writes: The composer.json file is configured to allow Symfony packages to be upgraded to patch versions., so ...
This command helped me to update symfony binary:
sudo symfony self-update
I'm having problem with the infamous:
"/Users/n/Library/Developer/Xcode/DerivedData/Build/Intermediates/XCBuildData/build.db":
database is locked Possibly there are two concurrent builds running in
the same filesystem location
How do I fix broken "modern" build system getting stuck with a locked database?
I tried:
Cleaning the project
Deleting derived data
Updating cocoapods (sudo gem...) and pod install
Full nuking of Xcode folder with a fresh reinstall from App Store
Now I'm with a fresh Xcode installation, the project worked for a dozen builds(real device and simulator) and the problem comes back, making me unable to work on a project. How I can reset the locks on build.db or delete it?
I see this question asked multiple times, and the answers do not solve my problem. I'm not using build scripts, all I have is a couple cocoapods. Please do not close this question, as I'm asking specifically about lack of:
NO CUSTOM SCRIPTS
NO CONSOLE BUILDS
NO COMPOSITE TARGETS
The only thing that lets me continue working is turning to the legacy build system:
How can I use the legacy build system with Xcode 10's `xcodebuild`?
Xcode 10: unable to attach DB error
I encountered this when tinkering with cli, swift run democli. The error I got was:
unable to attach DB: error: accessing build database "/Users/xman/Desktop/democli/.build/x86_64-apple-macosx/build.db": database is locked Possibly there are two concurrent builds running in the same filesystem location.
I just remove the build.db, and the DB error is gone.
So far the only way to fix this is to turn the "Legacy Build system" on in File > Workspace settings. After certain number of computer restarts (or time elapsed?) the setting can be changed to the "new" build system again and it will build.
I managed to compile my project by adding to the xcodebuild command line:
OBJROOT="${OBJROOT}/DependentBuilds"
Thanks to this post: https://github.com/mattgallagher/CwlSignal/issues/24#issuecomment-396931001
I encountered the same issue while using Fastlane and the New Build System.
After switching from xcodebuild( ) to build_app( ), the issue was resolved.
The legacy build solution is too temporary. You can only use that from within XCode. You can't use it within VSCode, so you lose the Hot Reload sweetness.
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 am having trouble with my Meteor up, which is perfectly functional on localhost and on Modulus. When I try to deploy to a *.meteor.com instance the upload fails and I get a very cryptic error. The first line is the gist of it I guess
Error: not a tracked temp dir: /Users/valentin/.meteor/packages/velocity_core/.0.4.5.1dbi101++os.osx.x86_64+web.browser+web.cordova
I have tried installing and reinstalling velocity and tried deploying it with/without, the error persists. There are a bunch of hidden files in the folder the error points too. Deleting the one mention in the error simply creates new ones and throws an error again (naming a different folder though) Does anyone have an idea what it is about?
I had the same problem with another meteor package. It was solved after I delete everything from myapp/.meteor/local/ directory.
I think you can leave your local db there (myapp/.meteor/local/db), but I did not check if it still be working. (I've deleted all and probably it is the same as running meteor reset for your local project.)
OK, this seems to work: You have to manually downgrade the meteor version to 1.0.2.1, by editing .meteor/release and changing the version number. (There's a fix in dev, so it should be solved in a more complete fashion soon.)
Were you trying to deploy while your meteor app still ran in localhost? I faced the same problem for another package but resolved it by stopping my local meteor app first then deploy.
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/