SG desktop broken pipe error

We sporadically see this behavior where the SG desktop (on Centos 7.9) becomes unresponsive and fails to launch apps. I hesitate to describe it as “frozen” since by all appearances basic UI components continue to work (at the very least you’re able to continue to click the apps as normal). Assuming the user is patient enough, the condition sometimes resolves itself after several minutes of waiting and the user sometimes finds themselves on the receiving end of dozens of simultaneous application launches (stacked up from the multiple button pushes). This state is accompanied by the following error:

Traceback (most recent call last):
  File "/home/vincent.wang/.shotgun/bundle_cache/app_store/tk-desktop/v2.6.0/python/tk_desktop/desktop_engine_site_implementation.py", line 355, in _handle_button_command_triggered
    "trigger_callback", "__commands", six.ensure_str(name)
  File "/home/vincent.wang/.shotgun/bundle_cache/app_store/tk-desktop/v2.6.0/python/tk_desktop/communication_base.py", line 97, in call_no_response
    return self._proxy.call_no_response(name, *args, **kwargs)
  File "/home/vincent.wang/.shotgun/bundle_cache/app_store/tk-desktop/v2.6.0/python/tk_desktop/rpc.py", line 408, in call_no_response
    self._connection.send(pickle.dumps((False, name, args, kwargs)))
  File "/home/vincent.wang/.shotgun/bundle_cache/app_store/tk-desktop/v2.6.0/python/tk_desktop/rpc.py", line 174, in send
    self._conn.send_bytes(payload)
  File "/opt/Shotgrid/Python3/lib/python3.7/multiprocessing/connection.py", line 200, in send_bytes
    self._send_bytes(m[offset:offset + size])
  File "/opt/Shotgrid/Python3/lib/python3.7/multiprocessing/connection.py", line 404, in _send_bytes
    self._send(header + buf)
  File "/opt/Shotgrid/Python3/lib/python3.7/multiprocessing/connection.py", line 368, in _send
    n = write(self._handle, buf)
BrokenPipeError: [Errno 32] Broken pipe
BrokenPipeError: [Errno 32] Broken pipe

Since it is exceedingly difficult to reproduce, we’ve not been able to isolate a case for further investigation, but our best guess is the python process that Desktop forks off is stuck waiting on a resource, likely a socket to communicate with Desktop. Also, this condition seems to frequently coincide with a second Desktop (zombie?) python process, although this could be a complete red herring. Long story short, we’re not sure, since the internals of Desktop are enough of a black box to render troubleshooting non-trivial.

Anybody else experienced this issue or anything similar and had success resolving it?
2021-10-12_11-36

1 Like