I am running spyder in WSL on Ubuntu 18.04 LTS with XLaunch. When I run my code (no blank file, or anything), I get the following message in the console:
runfile('/home/picky/Research/trans_CGM_Multiprobes.py', wdir='/home/picky/Research') 02-Mar-22 22:18:21: sys:1: ResourceWarning: unclosed socket <zmq.Socket(zmq.PUSH) at 0x7f8a492549a0>
What does this mean, and how can I fix it?
I running Python Version 3.9.7 [GCC 7.5.0], Spyder 5.1.5, Ubuntu 18.04 LTS on WSL, Qt 5.9.7, PyQT5 5.9.2
Code (irrelevant, since everytime I f5 to run file, this happens):
# -*- coding: utf-8 -*-
"""
Author: Patrick
March 3rd 2022
"""
import numpy as np
which returns
In[32]:
"""
Author: Patrick
March 3rd 2022
"""
import numpy as np
02-Mar-22 22:35:41: sys:1: ResourceWarning: unclosed socket <zmq.Socket(zmq.PUSH) at 0x7f8a49238f40>
Q :
" What does this mean, and how can I fix it? "
A :
The MEANING : Spyder is to be blamed (except where WSL fail to emulate ipc: over W10 pipe)
and REMEDY : check for more recent updates, if available & notify Spyder developers to do a better self-healing code-design, that uses ZeroMQ best-practices to unlock and release all resources they setup internally in due tiame and fashion ( no offense, just be also informed that some recent ZeroMQ native API default might cause another level of code-refactoring, as assumed-only behaviours have started to fail (self)-execute after a new, other default value starts to turn such use of implicit-only-logic upside down - zmq.LINGER being one such potential cause for indefinite hanging zmq.PUSH-socket, instead of being .close()-ed, right due to such zmq.LINGER-related behaviour.
Spyder & similar IDE tools started to heavily use ZeroMQ internally many years ago, which -for obvious reasons- started to cause problems (not only when users instantiated own ZeroMQ Context()-s) colliding in using localhost resources. As internal Spyder crashes keep appearin (some salvageable with console/IDE soft-reset(s), some not) some Spyder's usage of ZeroMQ resources was not in all cases programmed in a robust-enough, self-healing manner -- some of internal crashes did indeed leave some of the ZeroMQ resources hung (as you've seen above). Reboot sometimes being the only way one had to resort to, so as to finally release'em