sys:1: ResourceWarning: 未关闭的套接字
我在 Ubuntu 18.04 LTS 上使用 XLaunch 在 WSL 中运行间谍程序。当我运行代码（没有空白文件或任何内容）时，我在控制台中收到以下消息： runfile('/home/picky/Research/trans_CGM_Multiprobes.py', wdir='/home/picky/Research') 22-Mar-22 22:18:21: sys:1: ResourceWarning: 未关闭的套接字 zmq.Socket(zmq.PUSH) at 0x7f8a492549a0>
这是什么意思，以及如何实现我可以修复它吗？
我运行 Python 版本 3.9.7 [GCC 7.5.0]， 蜘蛛5.1.5， WSL 上的 Ubuntu 18.04 LTS， Qt 5.9.7， PyQT5 5.9.2
代码（无关紧要，因为每次我 f5 运行文件时，都会发生这种情况）：
# -*- coding: utf-8 -*-
"""
Author: Patrick
March 3rd 2022
"""
import numpy as np
返回
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>
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>
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
答：< br>含义：Spyder 是罪魁祸首（除非 WSL 无法通过 W10 管道模拟
ipc:）和补救措施：检查是否有最新更新（如果有） &通知 Spyder 开发人员进行更好的自我修复代码设计，即使用 ZeroMQ 最佳实践来解锁和释放他们在适当的时间和方式内部设置的所有资源（无意冒犯，只是还请注意，最近的一些 ZeroMQ 本机 API 默认值可能会导致另一级别的代码重构，因为在新的其他默认值开始颠倒这种仅隐式逻辑的使用之后，仅假设行为开始失败（自）执行 -
zmq.LINGER是无限期挂起zmq.PUSH-socket 的潜在原因之一，而不是.close()-ed，这是正确的与这种与 zmq.LINGER 相关的行为，Spyder 和类似的 IDE 工具多年前就开始在内部大量使用 ZeroMQ，这出于明显的原因开始导致问题（不仅是当用户实例化自己的实例时）。 ZeroMQ Context()-s) 在使用本地主机资源时发生冲突，因为内部 Spyder 崩溃不断出现（有些可以通过控制台/IDE 软重置来挽救，有些则不能），某些 Spyder 对 ZeroMQ 资源的使用并非在所有情况下都以编程方式进行编程。足够健壮、自我修复的方式——一些内部崩溃确实导致一些 ZeroMQ 资源挂起（正如您在上面看到的）。重新启动有时是人们不得不求助的唯一方法，以便最终释放它们
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.LINGERbeing one such potential cause for indefinite hangingzmq.PUSH-socket, instead of being.close()-ed, right due to suchzmq.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