spyder: ZMQError: Address already in use when restarting the kernel
I have installed Anaconda (python 3.7) in my ubuntu 20.04 system and I am using Spyder. I am running CNN and while runs for some part of data it’s fine but when I run it for entire data (more that 100000) I am getting the following error:
an error occurred while starting the kernel
Steps that reproduce the problem:
- run the code
- running for about 20 minutes
- Spyder tries to restart the kernel
- error raised
Traceback (most recent call last):
File "/home/exx/anaconda3/lib/python3.7/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "/home/exx/anaconda3/lib/python3.7/runpy.py", line 85, in _run_code
exec(code, run_globals)
File "/home/exx/anaconda3/lib/python3.7/site‑packages/spyder_kernels/console/__main__.py", line 23, in
start.main()
File "/home/exx/anaconda3/lib/python3.7/site‑packages/spyder_kernels/console/start.py", line 284, in main
kernel.initialize()
File "/home/exx/anaconda3/lib/python3.7/site‑packages/traitlets/config/application.py", line 87, in inner
return method(app, *args, **kwargs)
File "/home/exx/anaconda3/lib/python3.7/site‑packages/ipykernel/kernelapp.py", line 567, in initialize
self.init_sockets()
File "/home/exx/anaconda3/lib/python3.7/site‑packages/ipykernel/kernelapp.py", line 271, in init_sockets
self.shell_port = self._bind_socket(self.shell_socket, self.shell_port)
File "/home/exx/anaconda3/lib/python3.7/site‑packages/ipykernel/kernelapp.py", line 218, in _bind_socket
return self._try_bind_socket(s, port)
File "/home/exx/anaconda3/lib/python3.7/site‑packages/ipykernel/kernelapp.py", line 194, in _try_bind_socket
s.bind("tcp://%s:%i" % (self.ip, port))
File "/home/exx/anaconda3/lib/python3.7/site‑packages/zmq/sugar/socket.py", line 173, in bind
super().bind(addr)
File "zmq/backend/cython/socket.pyx", line 542, in zmq.backend.cython.socket.Socket.bind
File "zmq/backend/cython/checkrc.pxd", line 28, in zmq.backend.cython.checkrc._check_rc
zmq.error.ZMQError: Address already in use
Versions:
- Spyder 4.2.1:
- Python 3.7.9:
- Qt 5.15.2:
- PyQt 5.15.2:
- Linux/5.4.0.65-generic:
- Ubuntu 20.04
Dependencies:
# Mandatory:
atomicwrites >=1.2.0 : 1.4.0 (OK)
chardet >=2.0.0 : 4.0.0 (OK)
cloudpickle >=0.5.0 : 1.6.0 (OK)
diff_match_patch >=20181111 : 20200713 (OK)
intervaltree >=3.0.2 : 3.1.0 (OK)
IPython >=7.6.0 : 7.20.0 (OK)
jedi =0.17.2 : 0.17.2 (OK)
jsonschema >=3.2.0 : 3.2.0 (OK)
keyring >=17.0.0 : 22.0.1 (OK)
nbconvert >=4.0 : 6.0.7 (OK)
numpydoc >=0.6.0 : 1.1.0 (OK)
parso =0.7.0 : 0.7.0 (OK)
pexpect >=4.4.0 : 4.8.0 (OK)
pickleshare >=0.4 : 0.7.5 (OK)
psutil >=5.3 : 5.8.0 (OK)
pygments >=2.0 : 2.7.4 (OK)
pylint >=1.0 : 2.6.0 (OK)
pyls >=0.36.2;<1.0.0 : 0.36.2 (OK)
pyls_black >=0.4.6 : 0.4.6 (OK)
pyls_spyder >=0.3.0 : 0.3.0 (OK)
qdarkstyle >=2.8 : 2.8.1 (OK)
qtawesome >=0.5.7 : 1.0.1 (OK)
qtconsole >=5.0.1 : 5.0.2 (OK)
qtpy >=1.5.0 : 1.9.0 (OK)
rtree >=0.8.3 : 0.9.4 (OK)
setuptools >=39.0.0 : 52.0.0.post20210125 (OK)
sphinx >=0.6.6 : 3.4.3 (OK)
spyder_kernels >=1.10.1;<1.11.0 : 1.10.1 (OK)
textdistance >=4.2.0 : 4.2.1 (OK)
three_merge >=0.1.1 : 0.1.1 (OK)
watchdog >=0.10.3 : 1.0.2 (OK)
xdg >=0.26 : 0.27 (OK)
zmq >=17 : 20.0.0 (OK)
# Optional:
cython >=0.21 : 0.29.21 (OK)
matplotlib >=2.0.0 : 3.3.0 (OK)
numpy >=1.7 : 1.19.2 (OK)
pandas >=1.1.1 : 1.1.0 (NOK)
scipy >=0.17.0 : 1.5.2 (OK)
sympy >=0.7.3 : 1.6.1 (OK)
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 1
- Comments: 15 (7 by maintainers)
According to the Jupyter team (we use the same architecture as them to run code), this is caused by slow to start kernels. It should be fixed in our latest version (5.2.1), when
jupyter-client7.1.0 is installed.Hi, I am having the same issue with Spyder 5.0.0. This occurs whenever I manually restart the kernel, even immediately after opening Spyder (I mean before running any code). The kernel restarts if I manually close the console, but the problem persists in the new console. I installed Spyder through conda, not standalone.
Claudio
Thanks for your response. The restart happened on its own after my code is running for long enough. As you mentioned it could be running out of memory/other resources since the code is working fine with less data. I will try to implement DDP in my code and will return back to you.