Opened 11 years ago

Closed 11 years ago

#3707 closed (wontfix)

Log 500 errors to file when in production

Reported by: yary h <…> Owned by: Adrian Holovaty
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:


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...


Attachments (1)

log_errs.patch (1.5 KB) - added by yary h <…> 11 years ago.
simple implementation

Download all attachments as: .zip

Change History (5)

Changed 11 years ago by yary h <…>

Attachment: log_errs.patch added

simple implementation

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

Triage Stage: UnreviewedDesign decision needed

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

comment:2 Changed 11 years ago by yary h <…>

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 11 years ago by James Bennett

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 11 years ago by Malcolm Tredinnick

Resolution: wontfix
Status: newclosed

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