forked from https://github.com/symfony/symfony
This PR was merged into the 3.4 branch.
Discussion
----------
[HttpKernel] Fix error logger when stderr is redirected to /dev/null
| Q | A
| ------------- | ---
| Branch? | 3.4
| Bug fix? | yes
| New feature? | no <!-- please update src/**/CHANGELOG.md files -->
| Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files -->
| Tickets | n/a <!-- prefix each issue number with "Fix #", if any -->
| License | MIT
| Doc PR | n/a
The HttpKernel Logger is meant to be used as a last resort logging mechanism when no logger has been explicitly configured (Monolog is not a dependency for instance).
For small apps, that can be more than enough.
But under some circumstances, it does not work. When you are using PHP-FPM, `stderr` is ignored by default (`catch_workers_output` is `false`) and so, logs are ignored as well. There is no issue with the official PHP Docker image as the setting has been explicitly set to `true`. Not an issue with Symfony CLI as well, as we also change the setting. Not a problem either with the PHP built-in server as it does not use PHP FPM anyway.
But, in many other places, where the setting has its default value, logs are lost (as you can imagine, it happened to me). As this feature is meant to be a fallback, I think it should always work, or at least, we need to make everything possible to make it work out of the box; that's why I've considered it a bug and hence a PR on 3.4.
This PR changes the default value for the output to `null`, which uses `error_log()` instead of `stderr` to log errors. Why is it better? The output of `error_log()` is controllable by the `error_logs` PHP ini setting and it is well understood by everyone (the default configuration should always work well); so it should work in most/more cases.
The other change (to be discussed) is to also log messages at the `ERROR` level and not just the `CRITICAL` ones.
/cc @dunglas
Commits
-------
|
||
---|---|---|
.github | ||
src/Symfony | ||
.appveyor.yml | ||
.editorconfig | ||
.gitignore | ||
.php_cs.dist | ||
.travis.yml | ||
CHANGELOG-3.0.md | ||
CHANGELOG-3.1.md | ||
CHANGELOG-3.2.md | ||
CHANGELOG-3.3.md | ||
CHANGELOG-3.4.md | ||
CODE_OF_CONDUCT.md | ||
composer.json | ||
CONTRIBUTING.md | ||
CONTRIBUTORS.md | ||
LICENSE | ||
link | ||
phpunit | ||
phpunit.xml.dist | ||
README.md | ||
UPGRADE-3.0.md | ||
UPGRADE-3.1.md | ||
UPGRADE-3.2.md | ||
UPGRADE-3.3.md | ||
UPGRADE-3.4.md | ||
UPGRADE-4.0.md |
Symfony is a PHP framework for web and console applications and a set of reusable PHP components. Symfony is used by thousands of web applications (including BlaBlaCar.com and Spotify.com) and most of the popular PHP projects (including Drupal and Magento).
Installation
- Install Symfony with Composer (see requirements details).
- Symfony follows the semantic versioning strictly, publishes "Long Term Support" (LTS) versions and has a release process that is predictable and business-friendly.
Documentation
- Read the Getting Started guide if you are new to Symfony.
- Try the Symfony Demo application to learn Symfony in practice.
- Master Symfony with the Guides and Tutorials, the Components docs and the Best Practices reference.
Community
- Join the Symfony Community and meet other members at the Symfony events.
- Get Symfony support on Stack Overflow, Slack, IRC, etc.
- Follow us on GitHub, Twitter and Facebook.
- Read our Code of Conduct and meet the CARE Team
Contributing
Symfony is an Open Source, community-driven project with thousands of contributors. Join them contributing code or contributing documentation.
Security Issues
If you discover a security vulnerability within Symfony, please follow our disclosure procedure.
About Us
Symfony development is sponsored by SensioLabs, led by the Symfony Core Team and supported by Symfony contributors.