使用 python 多处理模块缓冲/截断到文件的 Shell 脚本输出

Question

我有一个 python 框架，它必须将 bash 脚本作为插件执行。 我们使用 multiprocessing 模块创建工作进程，从 multiprocessing.JoinableQueue 中挑选插件详细信息并使用 subprocess.Popen() 执行插件。

据观察，shell 脚本生成的最终输出会被截断，最终导致整个执行过程浪费。

所以我们尝试转移到 python 线程，让维护子进程机制的工作人员生成 shell 脚本进程。并且截断不再发生。但是线程非常慢（由于 GIL），并且对信号和事件的响应也是不确定的（可能是由于 GIL 的发布时间）。

我在很多地方都读过，包括 stackoverflow 中的其他问题，多处理模块对标准输出进行缓冲。我们知道这是问题所在。但是无法找到合适的解决方案，因为我们无法从 python 中为 sys.stdout.flush 提供 shell 脚本必须回显到文件的数据。

我们还用一些样本尝试了 os.fsync，但没有发生截断。同样，它不能直接用于我们的目的，因为框架不知道由 shell 脚本创建的文件的名称。框架只取回最终存档。

我的问题是，有什么方法可以防止在多处理模块产生的进程中出现这种缓冲？ python解释器的-u选项在这里有帮助吗？或者对 /usr/lib64/python2.6/multiprocessing 中的 python 库进行任何修改会解决这个问题吗？

Answer 1

我们发现脚本内通过 ssh 发送的命令在其输出中被截断。

为此，我们使用了 ssh 的 -n 标志，从而解决了问题。没有更多的截断。 但这是一个奇怪的问题，只发生在 python 多处理环境中，任何试图将这种模型用于自己的目的的人都必须认真考虑。

-n 选项的手册页说

从 /dev/null 重定向标准输入（实际上，阻止从 标准输入）。这必须在 ssh 在后台运行时使用。一种 常见的技巧是使用它在遥控器上运行 X11 程序 机器。例如 ssh -n shadows.cs.hut.fi emacs & 将 在 shadows.cs.hut.fi 上启动一个 emacs，X11 连接将 通过加密通道自动转发。 SSH 程序将被置于后台。 （这不起作用，如果 ssh 需要询问密码或密码；另见 -f 选项。）