Opened 17 years ago
Closed 17 years ago
#3707 closed (wontfix)
Log 500 errors to file when in production
| Reported by: | Owned by: | Adrian Holovaty | |
|---|---|---|---|
| Component: | Core (Other) | Version: | dev |
| 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: | no | UI/UX: | no |
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)
Change History (5)
by , 17 years ago
| Attachment: | log_errs.patch added |
|---|
comment:1 by , 17 years ago
| Triage Stage: | Unreviewed → Design decision needed |
|---|
Hmm.. can't you just use the webserver's error log?
comment:2 by , 17 years ago
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 by , 17 years ago
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 by , 17 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → 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.
simple implementation