zfs 文件服务器,使用Paramiko在远程文件服务器上执行zfs命令完全可以为所有用户提供NFS/zfs...

我昨天对Paramiko做了两行代码的修改，这不应该(据我所知)有任何负面影响，我们的电话立即开始响起来，电子邮件收到的报告说，用户无法访问他们的NFS挂载的主目录，这是zfs文件系统。我征求了同事们的意见，每个人都困惑不解，为什么这次变革不仅没有实现我设定的目标，而且还为什么它如此之大以至于把所有的东西都给了大家。在

在使用Paramiko执行“zfs create”命令创建新用户的NFS主目录之后，我使用了时间。睡觉(5) Python的一行代码，给远程系统一个执行和处理命令的机会(有时特别是当NFS服务器处于压力之下时，命令实际生效可能需要一两秒钟的时间)。在

结果，我们似乎遇到了一个罕见的情况，5秒的延迟是不够的。所以我决定改成Python”时间。睡觉(5) 函数，改为使用Paramiko的频道接收退出状态()”函数来等待退出状态代码，这样所需的时间量是非常多的(不是任意的秒数)。在

以下是代码上的区别(为了减少诸如确定zfs路径和用户名等日常工作而删减)：

原版：ssh = paramiko.SSHClient()

ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())

ssh.connect("homedirserver.example.com")

# Create zfs share

command = "zfs create {0}/{1}".format(zfs_parent, username)

ssh.exec_command(command)

time.sleep(5)

# Confirm creation (this can fail without a time.sleep delay above)

command = "zfs list -H {0}/{1}".format(zfs_parent, username)

stdin, stdout, stderr = ssh.exec_command(command)

error = stderr.read().strip()

if error != "":

# log error, raise RuntimeError

新版本：

^{pr2}$

似乎在执行此操作时，“zfs create”命令作为一个进程存在于文件服务器上，永远不会完成。ps -eaf | grep "zfs create"将命令显示为文件服务器上的一个进程，该进程存在于原始调用程序的Ctrl+C之外。最令人惊讶的是，这似乎足以彻底搞乱从该服务器导出的所有zfs文件系统。在Ctrl+C并等待几分钟后，一切恢复正常，人们不再报告NFS中断。在

这是针对Paramiko 1.14.1和Python2.7.8的。执行/调用机器是solaris11.2，远程文件服务器(进程挂起的地方)是solaris11.1。在