为什么 Fabric 显示与服务器断开连接消息近 2 分钟?

发布于 2024-08-29 13:32:48 字数 1576 浏览 6 评论 0原文

Fabric 显示 Disconnecting from username@server... done. 大约 2 分钟后每当我发出 fab 命令时都会显示新的命令提示符。

使用向内部服务器和 Rackspace 云服务器发出的 Fabric 命令时,存在此问题。下面我包含了来自服务器的 auth.log,但我在 MacBook 上的日志中没有看到任何内容。

有什么想法吗?

服务器的 SSH auth.log,LogLevel VERBOSE

Apr 21 13:30:52 qsandbox01 sshd[19503]: Accepted password for mrankin from 10.10.100.106 port 52854 ssh2
Apr 21 13:30:52 qsandbox01 sshd[19503]: pam_unix(sshd:session): session opened for user mrankin by (uid=0)
Apr 21 13:30:52 qsandbox01 sudo:  mrankin : TTY=unknown ; PWD=/home/mrankin ; USER=root ; COMMAND=/bin/bash -l -c apache2ctl graceful
Apr 21 13:30:53 qsandbox01 sshd[19503]: pam_unix(sshd:session): session closed for user mrankin

服务器配置

  • 操作系统:Ubuntu 9.10 和 Ubuntu 6.10(使用这些操作系统测试了 4 个服务器)
  • OpenSSH:Ubuntu 软件包版本 1.5.1p1-6ubuntu2

客户端配置

  • 操作系统:Mac OS X 10.6.3
  • Fabric ver 0.9
  • Vritualenv ver 1.4.7
  • pip ver 0.7

用于测试的简单 fabfile.py

即使我仅使用以下 fabfile 运行 fab -H server_ip host_type ,问题仍然存在。

from fabric.api import run

def host_type():
    run('uname -s')

关于问题原因的思考

我不确定这个问题持续了多久,但自从我开始注意到使用 Fabric 缓慢的服务器断开连接以来,以下是一些发生的变化。

  1. 我使用 virtualenv 1.4.7、virtualenvwrapper 2.1 和 pip 0.7 重新创建了我的 virtualenv。不确定这是否相关,但这是一个想法,因为我从 virtualenv 中运行我的 fabfiles。
  2. 我启用了 OS X 的防火墙。 我禁用了 OS X 的防火墙,问题仍然存在,所以这不是问题所在。

Fabric displays Disconnecting from username@server... done. for almost 2 minutes prior to showing a new command prompt whenever I issue a fab command.

This problem exists when using Fabric commands issued to both an internal server and a Rackspace cloud server. Below I've included the auth.log from the server, and I didn't see anything in the logs on my MacBook.

Any thoughts as to what the problem is?

Server's SSH auth.log with LogLevel VERBOSE

Apr 21 13:30:52 qsandbox01 sshd[19503]: Accepted password for mrankin from 10.10.100.106 port 52854 ssh2
Apr 21 13:30:52 qsandbox01 sshd[19503]: pam_unix(sshd:session): session opened for user mrankin by (uid=0)
Apr 21 13:30:52 qsandbox01 sudo:  mrankin : TTY=unknown ; PWD=/home/mrankin ; USER=root ; COMMAND=/bin/bash -l -c apache2ctl graceful
Apr 21 13:30:53 qsandbox01 sshd[19503]: pam_unix(sshd:session): session closed for user mrankin

Server Configuration

  • OS: Ubuntu 9.10 and Ubuntu 6.10 (tested 4 servers with those OSes)
  • OpenSSH: Ubuntu package version 1.5.1p1-6ubuntu2

Client Configuration

  • OS: Mac OS X 10.6.3
  • Fabric ver 0.9
  • Vritualenv ver 1.4.7
  • pip ver 0.7

Simple fabfile.py Used for Testing

The problem persists even when I just run fab -H server_ip host_type with the following fabfile.

from fabric.api import run

def host_type():
    run('uname -s')

Thoughts on Cause of the Issue

I'm not certain how long this problem has persisted, but below are some things that have changed since I started to notice the slow server disconnect using Fabric.

  1. I recreated my virtualenv's using virtualenv 1.4.7, virtualenvwrapper 2.1, and pip 0.7. Not sure if this is related, but it is a thought since I run my fabfiles from within a virtualenv.
  2. I enabled OS X's firewall. I disabled OS X's firewall and the problem persisted, so this is not the issue.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

染火枫林 2024-09-05 13:32:48

解决方案

在我的 virtualenv 中发出以下命令后,问题不再存在:

pip install -U paramiko

这安装了 paramiko-1.7.6 和 pycrypto-2.0.1。以前,我有 paramiko-1.7.4 和 pycrypto-2.0.1。

鉴于 pycrypto 版本没有改变,看来 paramiko 是罪魁祸首。至少 paramiko 1.7.4 和 Fabric 0.9 之间似乎存在交互,通过将 paramiko 升级到 1.7.6 可以修复该交互。

注意:我在一个 virtualenv 中升级到 paramiko-1.7.6 并确认问题消失了。然后,我激活了另一个仍具有 paramiko-1.7.4 的 virtualenv,并确认问题仍然存在,确实如此。然后我将 paramiko 从 1.7.4 升级到 1.7.6,并确认问题在该 virtualenv 中也消失了。

Solution

The problem no longer persists after I issued the following command in my virtualenv:

pip install -U paramiko

This installed paramiko-1.7.6 and pycrypto-2.0.1. Previously, I had paramiko-1.7.4 and pycrypto-2.0.1.

Appears that paramiko was the culprit given that the pycrypto version didn't change. At a minimum there appears to be an interaction between paramiko 1.7.4 and Fabric 0.9 that is fixed by upgrading paramiko to 1.7.6.

Note: I upgraded to paramiko-1.7.6 in one virtualenv and confirmed that the problem went away. I then activated another virtualenv that still had paramiko-1.7.4 and confirmed that the problem still persisted, which it did. Then I upgraded paramiko from 1.7.4 to 1.7.6 and confirmed that the problem went away in that virtualenv as well.

白首有我共你 2024-09-05 13:32:48

感谢您在这里跟踪此事。我只想向所有读者指出,Paramiko 1.7.4 以前已知与 Fabric 0.9 兼容,但在过去一两周内,一些用户开始出现此问题或类似问题(断开连接超时),所以我猜测一些其他组件(Python 升级、远程服务器包升级等)正在发挥作用,引发 1.7.4 中的错误。

我将查看 Paramiko 1.7.5/1.7.6 的变更日志,并收集有关人们的平台/Python 版本/等的更多信息,以尝试查看是否出现某种模式。

编辑:针对此问题新创建的Redmine票证位于:http://code.fabfile.org/问题/show/158

Thanks for keeping track of this here. I just want to note for any readers that Paramiko 1.7.4 has been previously known to be stable with Fabric 0.9, but in the last week or two several users have started exhibiting this or similar problems (disconnect timeouts) so I'm guessing some other component (Python upgrade, or remote server package upgrade, or something) is coming into play that is tipping off a bug in 1.7.4.

I will be checking out the changelogs for Paramiko 1.7.5/1.7.6 and gathering more info about peoples' platforms/Python versions/etc, to try and see if a pattern emerges.

EDIT: Newly created Redmine ticket for this issue is here: http://code.fabfile.org/issues/show/158

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文