This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Logging hangs thread after detaching a StreamHandler's termi
Type: Stage:
Components: Library (Lib) Versions: Python 2.4
process
Status: closed Resolution: works for me
Dependencies: Superseder:
Assigned To: vinay.sajip Nosy List: vinay.sajip, yangzhang
Priority: normal Keywords:

Created on 2006-02-14 06:07 by yangzhang, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (5)
msg27511 - (view) Author: Yang Zhang (yangzhang) Date: 2006-02-14 06:07
Hi all,

After many hours, I think I've found a bug in the 
logging module!

If you add a (stdout) StreamHandler to a logger, then 
detach the terminal for that stdout, subsequent calls 
to log() will hang the calling thread.

To reproduce this, write the following scripts (this 
was a small test case I came up with - maybe there's 
something simpler):

$ cat tryhup.bash
#!/usr/bin/env bash
scp hup.* localhost:
ssh localhost './hup.bash ; while true ; do sleep 1 ; 
done'

$ cat hup.bash
#!/usr/bin/env bash
./hup.py &

$ cat hup.py
#!/usr/bin/env python
import time
import logging
f = file( '/tmp/hup.out', 'w' )
try:
        logging.basicConfig( filename = '/tmp/lup.out', 
filemode = 'w' )
        # XXX PROBLEM LINE BELOW
        logging.getLogger('').addHandler( logging.
StreamHandler() )
        while True:
                f.write( '-------\n' )
                f.flush()
                logging.critical( '======' )
                time.sleep(1)
finally:
        f.close()

Run ./tryhup.bash. It will sit in an idle spin. Monitor 
the files /tmp/hup.out and /tmp/lup.out. Hit Ctrl-C on 
tryhup to kill it. The python process is still running, 
but is stalled (the .out files are no longer changing).

If you remove the above labeled line, however, this 
doesn't happen.

Can anybody please acknowledge this bug? Any temporary 
workarounds to this problem? Thanks in advance for 
looking into this and for hearing me in!
msg27512 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2006-02-17 01:04
Logged In: YES 
user_id=308438

Please provide more information about your OS - I ran these
scripts on Ubuntu 5.10 and did not see the problems you
mention. The script continues to run (printing dashes to the
console), and hup.out/lup.out are also updated continuously. 

Also, note that the logging module merely opens the stream
passed to the StreamHander for output, so check if in
your configuration you get a hang just doing a write to
sys.stderr.
msg27513 - (view) Author: Yang Zhang (yangzhang) Date: 2006-02-17 07:16
Logged In: YES 
user_id=1207658

Hi, yes, after I submitted this bug I actually looked into 
logging.StreamHandler, and found that its code was not too 
complicated (as with everything Python :).

I tried some more experiments, and found that the problem is 
in stderr, which throws an exception. The problem was that I 
couldn't see the exception (and didn't suspect that's what 
was happening), so the fact that the next line never came 
out led me to believe that the thread froze.

Is stderr supposed to raise an exception like this? Is this 
a bug?

Unfortunately, it's hard for me to tell what's going on 
(what the exception is that's being thrown). How do I tell 
what it's raising? (stderr is no longer avail. after all) I 
don't know how to catch an exception of any type and (say) 
print its str or repr value to a file so that I can tell 
what's going on.
msg27514 - (view) Author: Yang Zhang (yangzhang) Date: 2006-02-17 07:17
Logged In: YES 
user_id=1207658

Hi, yes, after I submitted this bug I actually looked into 
logging.StreamHandler, and found that its code was not too 
complicated (as with everything Python :).

I tried some more experiments, and found that the problem is 
in stderr, which throws an exception. The problem was that I 
couldn't see the exception (and didn't suspect that's what 
was happening), so the fact that the next line never came 
out led me to believe that the thread froze.

Is stderr supposed to raise an exception like this? Is this 
a bug?

Unfortunately, it's hard for me to tell what's going on 
(what the exception is that's being thrown). How do I tell 
what it's raising? (stderr is no longer avail. after all) I 
don't know how to catch an exception of any type and (say) 
print its str or repr value to a file so that I can tell 
what's going on.
msg27515 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2006-02-19 21:34
Logged In: YES 
user_id=308438

I can't tell from the info you've given what the problem
might be (e.g. state of redirections), but as it doesn't
appear to be a logging bug, I'm closing this.

By default, raiseExceptions is set to 1 in the logging
package, so a handler's handleError should be called when an
exception is raised in a handler.

You catch an exception with a try/except clause, like so:

try:
  # code which raises some exception
except Exception, e:
  open('/tmp/exc.txt', 'w').write(str(e))



History
Date User Action Args
2022-04-11 14:56:15adminsetgithub: 42899
2006-02-14 06:07:50yangzhangcreate