gclean throws "ValueError: I/O operation on closed file" exception

[GoogleCodeExporter]

The first time I run gclean on a job, it throws these exceptions:

Traceback (most recent call last):
  File "/usr/lib/python2.5/logging/__init__.py", line 750, in emit
    self.stream.write(fs % msg)
ValueError: I/O operation on closed file
Traceback (most recent call last):
  File "/usr/lib/python2.5/logging/__init__.py", line 750, in emit
    self.stream.write(fs % msg)
ValueError: I/O operation on closed file
Traceback (most recent call last):
  File "/usr/lib/python2.5/logging/__init__.py", line 750, in emit
    self.stream.write(fs % msg)
ValueError: I/O operation on closed file
Traceback (most recent call last):
  File "/usr/lib/python2.5/logging/__init__.py", line 750, in emit
    self.stream.write(fs % msg)
ValueError: I/O operation on closed file

However, the operation functions properly (it does clean the job.)

This is on debian 5 x86_64. Probably wontfix.

Original issue reported on code.google.com by mrgh...@gmail.com on 15 Apr 2011 at 2:21

[GoogleCodeExporter]

Actually, happens on Ubuntu 10.10 as well.

Original comment by riccardo.murri@gmail.com on 15 Apr 2011 at 2:51

[GoogleCodeExporter]

Did not happen for me on Ubuntu 10.10 i386 testing.

Original comment by mrgh...@gmail.com on 15 Apr 2011 at 3:15

[GoogleCodeExporter]

committed hack in r1398. will try to fix better in next release.

Original comment by mrgh...@gmail.com on 15 Apr 2011 at 6:46

[GoogleCodeExporter]

Quick recap of the debugging session with Mike:

  * The stack trace is printed by `logging` in its `atexit` handler,
    i.e., it happens *after* our code has called the final sys.exit()
    so we have no way of influencing it.

  * The exception is caught and the traceback printed by some
    `handleError` method (presumably `FileHandler.handleError`).

  * However, setting `.raiseExceptions = False` on all the
    registered handlers in `logging._handlers` does not silence
    the traceback.

More investigation is needed, especially since we're not able to
reproduce the error consistently (except on Debian 5).

In particular: what handler is responsible for throwing the error?

Original comment by riccardo.murri@gmail.com on 15 Apr 2011 at 7:01

[GoogleCodeExporter]

No instances on this bug have been reported since release 1.0; hence, closing 
as WONTFIX.

Original comment by riccardo.murri@gmail.com on 10 Jul 2012 at 9:57

• Changed state: WontFix