Intermittent Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads

[alexanderilyin]

SDK intermittently causing fatal errors like this:

[sentry] DEBUG: atexit: got shutdown signal
[sentry] DEBUG: atexit: shutting down client
[sentry] DEBUG: Flushing HTTP transport
[sentry] DEBUG: background worker got flush request
[sentry] DEBUG: background worker flushed
[sentry] DEBUG: Killing HTTP transport
[sentry] DEBUG: background worker got kill request
[sentry] DEBUG: Killing HTTP transport
Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads

Thread 0x00007f4debd63700 (most recent call first):
  File "/usr/lib/python3.7/logging/__init__.py", line 1009 in flush
  File "/usr/lib/python3.7/logging/__init__.py", line 1029 in emit
  File "/usr/lib/python3.7/logging/__init__.py", line 894 in handle
  File "/usr/lib/python3.7/logging/__init__.py", line 1586 in callHandlers
  File "/usr/local/lib/python3.7/dist-packages/sentry_sdk/integrations/logging.py", line 85 in sentry_patched_callhandlers
  File "/usr/lib/python3.7/logging/__init__.py", line 1524 in handle
  File "/usr/lib/python3.7/logging/__init__.py", line 1514 in _log
  File "/usr/lib/python3.7/logging/__init__.py", line 1366 in debug
  File "/usr/local/lib/python3.7/dist-packages/sentry_sdk/worker.py", line 78 in kill
  File "/usr/local/lib/python3.7/dist-packages/sentry_sdk/transport.py", line 357 in kill
  File "/usr/local/lib/python3.7/dist-packages/sentry_sdk/transport.py", line 98 in __del__
  File "/usr/local/lib/python3.7/dist-packages/sentry_sdk/worker.py", line 118 in _target
  File "/usr/lib/python3.7/threading.py", line 870 in run
  File "/usr/local/lib/python3.7/dist-packages/sentry_sdk/integrations/threading.py", line 67 in run
  File "/usr/lib/python3.7/threading.py", line 926 in _bootstrap_inner
  File "/usr/lib/python3.7/threading.py", line 890 in _bootstrap

Current thread 0x00007f4df23a7700 (most recent call first):

• Python 3.7.9
• sentry-sdk==0.18.0

[alexanderilyin]

Probably disabling atexit could help.

17:05:21  [sentry] DEBUG: Setting up integrations (with default = True)
17:05:21  [sentry] DEBUG: Setting up previously not enabled integration logging
17:05:21  [sentry] DEBUG: Setting up previously not enabled integration stdlib
17:05:21  [sentry] DEBUG: Setting up previously not enabled integration excepthook
17:05:21  [sentry] DEBUG: Setting up previously not enabled integration dedupe
17:05:21  [sentry] DEBUG: Setting up previously not enabled integration atexit
17:05:21  [sentry] DEBUG: Setting up previously not enabled integration modules
17:05:21  [sentry] DEBUG: Setting up previously not enabled integration argv
17:05:21  [sentry] DEBUG: Setting up previously not enabled integration threading
17:05:21  [sentry] DEBUG: Enabling integration logging
17:05:21  [sentry] DEBUG: Enabling integration stdlib
17:05:21  [sentry] DEBUG: Enabling integration excepthook
17:05:21  [sentry] DEBUG: Enabling integration dedupe
17:05:21  [sentry] DEBUG: Enabling integration atexit
17:05:21  [sentry] DEBUG: Enabling integration modules
17:05:21  [sentry] DEBUG: Enabling integration argv
17:05:21  [sentry] DEBUG: Enabling integration threading

[untitaker]

Thanks, we didn't encounter this bug ourselves. Can you work on providing a minimal, reproducible example so we can attempt to fix?

[alexanderilyin]

Seems like the problem is coming from sentry_sdk.init( ... debug=True ... ) param, seems that disabling debug helped. I was happening more frequently when reporting transactions/spans and I'm not currently doing that. I don't have a reproducible case that I can share at the moment due to the intermittent error nature. Another thing that it's used in a Python CLI app.

[github-actions[bot]]

This issue has gone three weeks without activity. In another week, I will close it.

But! If you comment or otherwise update it, I will reset the clock, and if you label it Status: Backlog or Status: In Progress, I will leave it alone ... forever!

---

"A weed is but an unloved flower." ― Ella Wheeler Wilcox 🥀

[bergentroll]

I met the same error on project with django.core.management.base.BaseCommand subclass for custom manage.py subcommand. This subclass explicitely uses BaseCommand.stdout() and BaseCommand.stderr() for output. Error fires on python3 manage.py subcommand approximately in 1 of 3 runs. Therefore I failed to reproduce it in a clean minimal example.

sentry-sdk==1.5.1
python==3.9.6

shutdown_timeout=0 in sentry_sdk.init() eliminates an error.

[antonpirker]

Hello @bergentroll , can you assemble a Django project with a manage command where this error is happening so we can reproduce this?

[bergentroll]

Hello, @antonpirker. I am sorry, it is too hard to do.

[nikolas]

We're seeing this error when using the sentry python sdk in conjunction with Django's file logger:

 [sentry] DEBUG: atexit: got shutdown signal
 [sentry] DEBUG: atexit: shutting down client
 [sentry] DEBUG: Flushing HTTP transport
 [sentry] DEBUG: background worker got flush request
 [sentry] DEBUG: background worker flushed
 [sentry] DEBUG: Killing HTTP transport
 [sentry] DEBUG: background worker got kill request
 [sentry] DEBUG: Killing HTTP transport
Fatal Python error: could not acquire lock for <_io.BufferedWriter name='<stderr>'> at interpreter shutdown, possibly due to daemon threads
Python runtime state: finalizing (tstate=0x1dbfca0)

Thread 0x00007fce9ecd2700 (most recent call first):
  File "/usr/lib/python3.8/logging/__init__.py", line 1069 in flush
  File "/usr/lib/python3.8/logging/__init__.py", line 1089 in emit
  File "/usr/lib/python3.8/logging/__init__.py", line 954 in handle
  File "/usr/lib/python3.8/logging/__init__.py", line 1661 in callHandlers
  File "/var/www/wardenclyffe/releases/blue/wardenclyffe/ve/lib/python3.8/site-packages/sentry_sdk/integrations/logging.py", line 96 in sentry_patched_callhandlers
  File "/usr/lib/python3.8/logging/__init__.py", line 1599 in handle
  File "/usr/lib/python3.8/logging/__init__.py", line 1589 in _log
  File "/usr/lib/python3.8/logging/__init__.py", line 1434 in debug
  File "/var/www/wardenclyffe/releases/blue/wardenclyffe/ve/lib/python3.8/site-packages/sentry_sdk/transport.py", line 492 in kill
  File "/var/www/wardenclyffe/releases/blue/wardenclyffe/ve/lib/python3.8/site-packages/sentry_sdk/transport.py", line 113 in __del__
  File "/var/www/wardenclyffe/releases/blue/wardenclyffe/ve/lib/python3.8/site-packages/sentry_sdk/worker.py", line 123 in _target
  File "/usr/lib/python3.8/threading.py", line 870 in run
  File "/var/www/wardenclyffe/releases/blue/wardenclyffe/ve/lib/python3.8/site-packages/sentry_sdk/integrations/threading.py", line 67 in run
  File "/usr/lib/python3.8/threading.py", line 932 in _bootstrap_inner
  File "/usr/lib/python3.8/threading.py", line 890 in _bootstrap

Current thread 0x00007fcea4c22740 (most recent call first):
<no Python frame>
bash: line 1: 3015728 Aborted                 (core dumped) nice ./manage.py migrate --

[nikolas]

Lately, I've only seen this issue occur during Django's collectstatic and migrate steps. This error can be worked around by not initializing sentry_sdk during the collectstatic process. For example, in your settings file:

if 'collectstatic' not in sys.argv and 'migrate' not in sys.argv:
    sentry_sdk.init(
        dsn=SENTRY_DSN,
        integrations=[DjangoIntegration()],
        debug=True,
    )

[antonpirker]

I have again tried to reproduce this. And I could not. Sorry, but without a reproduction I can not do anything. I tried with SDK version 1.5.1 and with a custom BaseCommand and migrate and collectstatic.

Because this has been reported with very old SDK version (0.18.0 and 1.5.1) I will close this now.

If someone can supply a reproduction of this issue than please open up another issue and link to this one. I will close this.