Ticket #852 (defect)
Opened 3 months ago
Last modified 2 months ago
CherryPy always overrides user specified log levels
Status: assigned
| Reported by: | Bjoern (askadar@gmail.com) | Assigned to: | fumanchu (accepted) |
|---|---|---|---|
| Priority: | high | Milestone: | 3.1 |
| Component: | CherryPy code | Keywords: | |
| Cc: |
CherryPy unconditionally sets the log level for loggers used by cherrypy to DEBUG for error logs and INFO for access logs. This may override log levels configured by the user since this is done during startup.
From IRC:
[04:40am] askadar: I just want to log everything to sys.stdout, but not the requests since the access log is being written by lighttpd anyway
....
[04:40am] askadar: so no matter what I do the root logger, access records are still being written to stdout
....
[04:43am] Lawouach_: setting the log.screen : False doesn't work as expected?
[04:44am] askadar: I want to disable the default logging
[04:44am] askadar: and have only the root logger write to stdout
[04:44am] askadar: log.screen: False turns of all logging
[04:44am] askadar: by introducing the root logger with level WARNING, cherrypy's internal stuff suddenly starts to log again,too
[04:44am] askadar: and that is very unexpected
[04:45am] Lawouach_: I see
[04:45am] askadar: I had hoped to filter all access records by setting the root logger level to WARNING, since access stuff is level INFO
[04:45am] Lawouach_: If you think there is a design issue here you ought to open a ticket with an alternative (patch are even better but not mandatory
There is no reason why CherryPy should set these levels, especially not in production environments. The solution is to just leave the setting alone. Patch is attached.
Attachments
Change History
09/02/08 05:08:59: Modified by Bjoern (askagar@gmail.com)
09/02/08 05:10:25: Modified by Bjoern (askagar@gmail.com)
- attachment logging.patch added.
09/27/08 20:52:06: Modified by fumanchu
- status changed from new to assigned.
OK. Mostly agreed. In [2046] I removed the setLevel calls on the Handler objects. However, I wonder if we shouldn't keep the ones on the Logger objects; they're easy enough to override if you want:
cherrypy.log.error_log.setLevel(logging.NOTSET) cherrypy.log.access_log.setLevel(logging.NOTSET)
...and a similar incantation for app.log. I hesitate to make them both NOTSET by default, since A) this would break some backward compatibility and B) I wonder how that would interact with other libs in the same process (say, an ORM or templating library) that also use the logging module. Trusting them all to have similar ideas about what the various levels mean seems brittle. Thoughts?
I forgot to mention, there is a workaround.
Execute the following function *after* cherrypy.mount() and cherrypy.server.quickstart():
def fixup_cherrypy_logs(): loggers = logging.Logger.manager.loggerDict.keys() for name in loggers: if name.startswith('cherrypy.'): print "Fixing %s." % name logging.getLogger(name).setLevel(0)This resets the log levels so that the final decisions is made by the root logger.