Why Symfony dies with a 500 error without Monolog writing anything to the log file?-CodePudding

I'm attempting to have more information on production when my site errors out. The scenario is this:

We integrate with stripe, and stripe webhooks to do certain calls. When a stripe function fails, we don't have any information to understand what went wrong on our production server. Currently stripe returns this sort of error:

It's unhelpful for sure, but my hope is that the prod.log file within var/log/prod.log file would have information. I take a look and it's empty (not ideal - now we don't know what the problem is at all).

My monolog.yaml file for production is as follows:

monolog:
    handlers:
        filter_for_errors:
            type: fingers_crossed
            # if *one* log is error or higher, pass *all* to file_log
            action_level: error
            handler: file_log

        # now passed *all* logs, but only if one log is error or higher
        file_log:
            type: stream
            path: "%kernel.logs_dir%/%kernel.environment%.log"

        # still passed *all* logs, and still only logs error or higher
        syslog_handler:
            type: syslog
            level: error

This is standard, straight from the docs, however, it still seems as though nothing is getting written to that file.

I'm checking permissions for that file:

-rw-r--r-- 1 deploy www-data 488007 Mar  2 19:21 prod.log

Are those the right permissions?

Does my nginx server block configuration need to point to the right file as well or is symfony enough for this?

CodePudding user response：

That file should be writtable by the same user who owns the webserver process. It's usually www-data, but check your server configuration.

Usually everything under var should be writable by the web-server process.

Checking the docs about the recommended directory permissions for a Symfony project is always a recommended course of action in case of doubt.

Also, trying to replicate the production environment as closely as possible on dev and on production. If you reproduced this issue on development, you could have enabled display_errors on PHP and you'd see the ultimate cause.

What's happening here is that when anything that triggers writing to the log happens, the application will encounter a fatal error because it can't write the the log files. So even if the original error was non-fatal, even a warning or informational, it gets escalated to a 500 because not being able to write to a location where the application expects to, it's a non-recoverable error.