Deadlock when running alongside sh package

We have noticed a reproducible deadlock when running Sentry SDK (0.19.5) alongside sh (1.14.1) on Python 3.7.6 and 3.9.1.

The following works:

import sh
sh.cat(sh.false(_piped=True))

The following hangs:

import sentry_sdk
from sentry_sdk.integrations.logging import LoggingIntegration
import logging

SENTRY_URL = "..."

sentry_sdk.init(
    SENTRY_URL,
    integrations=[
        LoggingIntegration(
            event_level=logging.ERROR
        )
    ],
    debug=True,
)

import sh
sh.cat(sh.false(_piped=True)) # This hangs

After issuing SIGINT (Ctrl-C), I get the following output:

...
sh.cat(sh.false(_piped=True))
^C [sentry] DEBUG: Sending event, type:null level:error event_id:<redacted> project:<redacted> host:o238679.ingest.sentry.io
Exception in thread background thread for pid 6751:
Traceback (most recent call last):
  File "/usr/lib64/python3.7/threading.py", line 926, in _bootstrap_inner
    self.run()
  File "/usr/local/lib/python3.7/site-packages/sentry_sdk/integrations/threading.py", line 69, in run
    reraise(*_capture_exception())
  File "/usr/local/lib/python3.7/site-packages/sentry_sdk/_compat.py", line 54, in reraise
    raise value
  File "/usr/local/lib/python3.7/site-packages/sentry_sdk/integrations/threading.py", line 67, in run
    return old_run_func(self, *a, **kw)
  File "/usr/lib64/python3.7/threading.py", line 870, in run
    self._target(*self._args, **self._kwargs)
  File "/usr/local/lib/python3.7/site-packages/sh.py", line 1637, in wrap
    fn(*rgs, **kwargs)
  File "/usr/local/lib/python3.7/site-packages/sh.py", line 2561, in background_thread
    handle_exit_code(exit_code)
  File "/usr/local/lib/python3.7/site-packages/sh.py", line 2265, in fn
    return self.command.handle_command_exit_code(exit_code)
  File "/usr/local/lib/python3.7/site-packages/sh.py", line 865, in handle_command_exit_code
    raise exc
sh.ErrorReturnCode_1:

  RAN: /usr/bin/false

  STDOUT:


  STDERR:


---------------------------------------------------------------------------
KeyboardInterrupt                         Traceback (most recent call last)
<ipython-input-2-62608a14b5f4> in <module>
      1 import sh
----> 2 sh.cat(sh.false(_piped=True)) # This hangs

/usr/local/lib/python3.7/site-packages/sh.py in __call__(self, *args, **kwargs)
   1518             stderr = open(str(stderr), "wb")
   1519
-> 1520         return RunningCommand(cmd, call_args, stdin, stdout, stderr)
   1521
   1522

/usr/local/lib/python3.7/site-packages/sh.py in __init__(self, cmd, call_args, stdin, stdout, stderr)
    782
    783             if should_wait:
--> 784                 self.wait()
    785
    786     def wait(self, timeout=None):

/usr/local/lib/python3.7/site-packages/sh.py in wait(self, timeout)
    846                 # main thread.  this allows them to bubble up
    847                 if self.process._stdin_process:
--> 848                     self.process._stdin_process.command.wait()
    849
    850             self.log.debug("process completed")

/usr/local/lib/python3.7/site-packages/sh.py in wait(self, timeout)
    829
    830             else:
--> 831                 exit_code = self.process.wait()
    832                 self._waited_until_completion = True
    833

/usr/local/lib/python3.7/site-packages/sh.py in wait(self)
   2486             timer.cancel()
   2487
-> 2488             self._background_thread.join()
   2489
   2490             if witnessed_end:

/usr/lib64/python3.7/threading.py in join(self, timeout)
   1042
   1043         if timeout is None:
-> 1044             self._wait_for_tstate_lock()
   1045         else:
   1046             # the behavior of a negative timeout isn't documented, but

/usr/lib64/python3.7/threading.py in _wait_for_tstate_lock(self, block, timeout)
   1058         if lock is None:  # already determined that the C code is done
   1059             assert self._is_stopped
-> 1060         elif lock.acquire(block, timeout):
   1061             lock.release()
   1062             self._stop()

KeyboardInterrupt:

Is there an obvious method for avoiding this deadlock?

[untitaker]

You can run with default_integrations=False to disable the ThreadingIntegration. That will likely solve your issue.

[antonpirker]

As there was a solution (“instrument sh by hand”) I will close this issue. I know this is not the optimal solution, but if someone can supply a PR that fixes this issue, I am more then happy to help you bring it into a shape so we can merge it!