【问题标题】:zmq.Context() hangs a few minutes after bootzmq.Context() 在启动后挂起几分钟
【发布时间】:2018-07-12 10:09:37
【问题描述】:

在一个非常小的非工作示例中,我这样做:

import zmq
ctx = zmq.Context()

python3 -c "import zmq; ctx = zmq.Context()"

当我的机器运行几分钟后,它运行良好。但是,在启动后(大约 2 分钟)它没有。它只是阻塞并且不间断(即使Ctrl+C 不工作)。

在机器正常运行的最初几分钟内可能会出现任何冲突的想法?

信息:libzmq5 版本是 4.2.5 和 pyzmq 17.0.0。

编辑:C example 的行为相同。

Edit2:感谢strace,我知道它挂在系统调用getrandom(上。据我所知,它似乎是从没有获得足够熵的/dev/random 请求而不是使用/dev/urandom。事实上,cat /dev/random 也会阻止,而 cat /dev/urandom 不会。

【问题讨论】:

标签: python c python-3.x zeromq pyzmq


【解决方案1】:

你确定它真的挂在那里吗?我有同样的问题,但我一直认为在第一次使用加密连接时它会挂起。

问题是在启动时内核没有熵并且从 /dev/random 或 /dev/urandom 读取挂起。在使用 zmq 之前,您需要在启动时创建一些熵。通常,随机种子会在关机时存储,并用于在开机时播种熵。确保在您使用 zmq 之前发生了这种情况并且它有效。

就我而言,我必须使用 havegd 向系统添加熵。

注意:熵必须在 zmq 启动之前存在。不要问我为什么。我也有兴趣知道。

【讨论】:

  • 它肯定挂在zmq.Context(),MWE 没有别的要求。因此,不涉及加密等。但是,对我来说,这是一个内核问题。从4.16.0-2-amd64 #1 SMP Debian 4.16.16-2 (2018-06-22) x86_64 GNU/Linux 降级到4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux 后,它按预期工作。
猜你喜欢
  • 2014-07-09
  • 1970-01-01
  • 1970-01-01
  • 2020-11-01
  • 1970-01-01
  • 2012-03-15
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多