classification
Title: logging.shutdown should cope with IO errors from handler.release methods
Type: behavior Stage: resolved
Components: Versions: Python 3.2, Python 3.3, Python 2.7
process
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: vinay.sajip Nosy List: ncoghlan, vinay.sajip
Priority: normal Keywords:

Created on 2012-09-18 07:40 by ncoghlan, last changed 2012-09-20 14:35 by vinay.sajip. This issue is now closed.

Messages (4)
msg170635 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2012-09-18 07:40
logging.shutdown includes a try/except block to avoid emitting spurious IO errors while the interpreter is shutting down. This fails if a registered handler tries to do IO (such as calling flush()) in its release method.

It would be better if the flush-and-close block was written as:

  try:
      hr.acquire()
      try:
          hr.flush()
          hr.close()
      finally:
          hr.release()
  except (IOError, ValueError):
    # Tolerate handlers that try to do IO in release()
msg170647 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2012-09-18 14:49
I'm not against making this change, but I'm curious - why would a handler do clean-up I/O in its release() method (which is just for releasing the I/O lock) where it could just as easily override the close() method to do the same thing? It seems like programmer error to be doing any I/O in a handler after close() is called on it.
msg170698 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2012-09-19 03:45
The particular app that is getting affected is clearing out and rebuilding the logging configuration without restarting in response to a notification that the application config has changed. This was working OK on 2.6, but started misbehaving when ported to 2.7.

It's http://pypi.python.org/pypi/ConcurrentLogHandler that's calling self.stream.flush() inside release(), and I suspect that *is* a bug on that side as well.

It's also possible that we should just be skipping the use of ConcurrentLogHandler entirely on 2.7, but I haven't looked into the feasibility of that as yet.

This specific bug report is just because I noticed that the stdlib is *trying* to be tolerant of handler misbehaviour, but not quite succeeding in this particular case. Perhaps we should be writing something out to stderr when ignoring one of these errors?
msg170807 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2012-09-20 12:16
Dan and Amit worked out a patch for ConcurrentLogHandler (https://bugzilla.redhat.com/show_bug.cgi?id=858912) so I'm OK with rejecting this one.
History
Date User Action Args
2012-09-20 14:35:32vinay.sajipsetstatus: open -> closed
assignee: vinay.sajip
resolution: wont fix
stage: resolved
2012-09-20 12:16:32ncoghlansetmessages: + msg170807
2012-09-19 03:45:14ncoghlansetmessages: + msg170698
2012-09-18 14:49:31vinay.sajipsetmessages: + msg170647
2012-09-18 07:41:01ncoghlansetnosy: + vinay.sajip
type: behavior
2012-09-18 07:40:20ncoghlancreate