-1

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:

enter image description here

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?

Majo0od
  • 2,278
  • 10
  • 33
  • 58
  • [How do I fix a couple of issues in my symfony production project](https://stackoverflow.com/q/71328331/1426539), [How to improve my production environment's error reporting in symfony?](https://stackoverflow.com/q/71342188/1426539), [How do I log production errors in a symfony project](https://stackoverflow.com/q/71346742/1426539), plus the two you have open at this moment. Too many almost identical questions for the same basic issue. – yivi Mar 04 '22 at 21:48
  • All of those are deleted - tried to make this more specific. – Majo0od Mar 04 '22 at 22:28

1 Answers1

1

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.

yivi
  • 42,438
  • 18
  • 116
  • 138
  • If I understand what youre saying correctly, you're saying when landing on a 404, its trying to log it, but its returning a 500 because it's not writable? – Majo0od Mar 05 '22 at 01:10
  • (or potentially that issue) – Majo0od Mar 05 '22 at 01:10
  • When I ran `bin/console logs all` I got the following error: `The stream or file "/var/www/website/symfony/releases/20220302194759/var/log/prod.log" could not be opened in append mode: Failed to open stream: Permission denied` When I checked the permissions they were: `-rw-r--r-- 1 deploy www-data 488007 Mar 2 19:21 prod.log` - deploy is the user I use to deploy the application. – Majo0od Mar 05 '22 at 03:08
  • You need to reset the permissions correctly after deploying. That's a bit outside of the scope of the question, again. First you need to understand permissions and which users need to read/write the file: `www-data` needs permissions, because otherwise there is no logging. If you need to do things locally (`bin/console`) that produce logging, the user that run that command would also need permissions, etc. How *exactly* would depend on your circumstances. – yivi Mar 05 '22 at 07:26
  • The link to the docs shows you the best way of doing it, using ACL, but I don't know if that's feasible for you. Otherwise you'll need to set up ownership/permissions masks that fit in your case, from a worst case scenario that simply gives `var/log` `777` and `var/log/*` `666`; to something cleaner where you add all users that need writing to a "logwriters` group and change group ownership (`chgrp`) during deployment. I explained you what's happening and what needs doing, but now you need to walk the rest of the way. – yivi Mar 05 '22 at 07:29
  • So my log file is working properly now, and yet the server is STILL returning an error 500 instead of 404 for pages not found... – Majo0od Mar 07 '22 at 15:30
  • Something else than the 404 is triggering the 500 (_during_ the request that triggered the 404). Now that you have a functioning error log, check it to see what's causing a fatal error. – yivi Mar 07 '22 at 15:37
  • That's the thing, it's not showing fatal errors. I have to update my monolog.yaml file I believe to get it to do that. – Majo0od Mar 07 '22 at 15:43