After troubleshooting this for a while I've identified the cause as https://github.com/gnuradio/gnuradio/issues/1132 and opened https://github.com/gnuradio/gnuradio/pull/3866 to resolve it. The backtrace clearly shows the channel is sitting in some see code in a ZMQ poll() with a timeout of -1, which was the default ZMQ_LINGER (the documentation incorrectly had the default as 30s).
Once that PR closes all existing sites can be updated to gr 3.8 and python 3, although I'd like to do some performance/cpu use testing on the new ZMQ sub/sink setup.
Completed a 1 week test run with no receiver lockups on gr 3.8 w/ the linked patch, issue resolved, although backport PR hasn't been merged yet so custom compiles will be required.
After troubleshooting this for a while I've identified the cause as https://github.com/gnuradio/gnuradio/issues/1132 and opened https://github.com/gnuradio/gnuradio/pull/3866 to resolve it. The backtrace clearly shows the channel is sitting in some see code in a ZMQ poll() with a timeout of -1, which was the default ZMQ_LINGER (the documentation incorrectly had the default as 30s).
Once that PR closes all existing sites can be updated to gr 3.8 and python 3, although I'd like to do some performance/cpu use testing on the new ZMQ sub/sink setup.