Log only real fatal errors from PHP-FPM in Docker container

I’m using NGINX with PHP-FPM in seperated Docker containers. I want to get errors only to stderr, so that I can collect them on a centralized log-server. Problem is: I’m using WP and seems to have some not well written plugins. They work but cause warnings like this:

2017/06/17 01:16:08 [error] 7#7: *1 FastCGI sent in stderr: “PHP
message: PHP Warning: Parameter 1 to wp_default_scripts() expected to
be a reference, value given in /www/wp-includes/plugin.php on line 601

  • Run Chromium inside container: libGl error
  • Dokku DigitalOcean Deploy (Cannot access Rails Sample App)
  • Flocker data migration
  • Docker - check within the container if a directory is mounted from the host or not
  • Error Docker deployment in Amazon Elastic Beanstalk - Docker container quit unexpectedly
  • How do I run private docker images on Google Container Engine
  • Example script for testing, which should give me a fatal error in the stderr:


    PHP-FPM was configured to log errors to stderr like this:

    log_level = error
    error_log = /proc/self/fd/2

    I’m wondering that this gave me nothing in the script above. Just after I switched the log_level to at least notice, I got the exception on the console of the docker container:

    [17-Jun-2017 01:45:35] WARNING: [pool www] child 8 said into stderr:
    “NOTICE: PHP message: PHP Fatal error: Uncaught Error: Call to
    undefined function not_existing_func() in /www/x.php:2”

    Why the hell is this a notice? For me we’ve clearly a fatal error here like the message indicates, cause the script can’t continue (and we get a 500 error in the browser, of course). It can’t be true that I have to set log_level to notice so that I don’t miss fatal errors which are delcared as warnings. And simultaneously, my logs get filled with trash warnings from wordpress themes, plugins and so on, that I haven’t developed and I don’t want to fix for update reasons…

    I tried a bit and found out that log_errors in php.ini is essential for PHP-FPM to get any information. But the log level from error_reporting seems wired too. For testing purpose, I used the following configuration:

    display_errors = Off
    log_errors = On
    error_log = /proc/self/fd/2
    ;error_reporting = E_COMPILE_ERROR|E_ERROR|E_CORE_ERROR
    error_reporting = 0

    Result: I got notices, but NO info about my fatal error…

  • Why are Docker build commands running so slow in Elastic Beanstalk?
  • ERR_EMPTY_RESPONSE for localhost when running Docker
  • How to run custom Docker file?
  • docker-compose build error ubuntu mango
  • How does one detect if one is running within a docker container within Python?
  • Where should live docker volumes on the host?
  • One Solution collect form web for “Log only real fatal errors from PHP-FPM in Docker container”

    First of all, I learned that I was wrong: WordPress is the root cause for this issue, not PHP directly. It’s a known fact that WP manipulates the error_reporting when debugging is enabled, so I checked to define WP_DEBUG as false in my config. BUT even having this set, the documentation says

    Except for ‘error_reporting’, WordPress will set this to 4983 if WP_DEBUG is defined as false.

    So my settings to php.ini were correct and sufficient. I don’t even need the php-fpm settings, when errors are redirected to stdout in the php.ini file.

    How to prevent WordPress from manipulating the error reporting?

    This is not so easy, too. Although the WordPress documentation says, that the wp-config.php is a good place to set global wide settings like the error reporting, they god overwritten later to 4983. I don’t know where. Maybe it’s not even the Core of wordpress, but some poor developed plugin or theme.

    We can handle this by adding error_reporting to the disabled functions:

    disable_functions = error_reporting

    Now it’s not possible to overwrite our error_reporting. I think this is the best solution to make sure, that we don’t get any other error reporting by external influence from plugins or themes. Also in the future. Since PHP allows such chaos, we need to reckon with such things.

    Basically, we could criticize, that this pevent us from getting more logs by setting WP_DEBUG to true. That’s right. But as we’re on a productive system, It seems wrong for me do to troubleshooting in such a way there. We shouldn’t do this on a application base, especially without display_errors! Instead, the workflow to find problems should be a look at the error logs.

    Fatal errors should always be logged and checked on a regular basis. If that is not enough, error_reporting could be set on a higher level to get information about possible problems like warnings.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.