Opened 8 years ago

Closed 8 years ago

#3707 closed (wontfix)

Log 500 errors to file when in production

Reported by: yary h <not.com@…> Owned by: adrian
Component: Core (Other) Version: master
Severity: Keywords: error log
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

My webhost doesn't allow email in or out. My django app is giving me an error in their environment, but not in my dev.

I'd like a setting to log 500 errors to a local file, so I can check that and see if there are problems, since email isn't an option.

I'm working on a patch for a ERROR_LOG setting, will submit once its working. Let me know if this exists already...

thanks!

Attachments (1)

log_errs.patch (1.5 KB) - added by yary h <not.com@…> 8 years ago.
simple implementation

Download all attachments as: .zip

Change History (5)

Changed 8 years ago by yary h <not.com@…>

simple implementation

comment:1 Changed 8 years ago by Simon G. <dev@…>

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Design decision needed

Hmm.. can't you just use the webserver's error log?

comment:2 Changed 8 years ago by yary h <not.com@…>

You're making assumptions about my webserver's error log that aren't warrented :-) Depends on the error, the log was good enough up until tonight...

comment:3 Changed 8 years ago by ubernostrum

Unfortunately, I don't think we can afford to work around every conceivable setup; the web server log is where this data should end up, and (on a couple sites I just checked) does end up under both Apache/mod_python and lighttpd/FastCGI. Unless there's something I'm missing here, I'm inclined to mark this wontfix and keep responsibility for proper logging on the web server's side of things.

comment:4 Changed 8 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from new to closed

This patch is not thread- or multi-process safe -- messages will get interspersed with each other (which can't always be avoided without a lot of work, but we should try a little bit). Also, we shouldn't be reimplementing file logging for a webserver. The stderr output file descriptor exists for this purpose and we should be using it, if we are going to do this in core. The problem with that is that this is going to log a _lot_ of information each time there's a problem (and often when such a problem occurs, it happens more than once until it is attended to).

This could be implemented as a piece of middleware, instead. That way it can be dropped in just when wanted, without needing to put it in the main code.

I think I'm going to wontfix this for now. A piece of middleware that used Python's standard logging module (so was properly configurable) for this purpose -- logging particular HTTP error codes -- might be worth considering for contrib/, though.

Note: See TracTickets for help on using tickets.
Back to Top