打印时IOError输入/输出错误 [英] IOError Input/Output Error When Printing

问题描述

由于在打印调用期间出现输入/输出错误，我继承了一些定期（随机）失败的代码。我试图确定引发异常的原因（或至少，更好地理解它）以及如何正确处理它。

I have inherited some code which is periodically (randomly) failing due to an Input/Output error being raised during a call to print. I am trying to determine the cause of the exception being raised (or at least, better understand it) and how to handle it correctly.

执行以下Python行时（在2.6.6翻译中，在CentOS 5.5上运行）：

When executing the following line of Python (in a 2.6.6 interpreter, running on CentOS 5.5):

print >> sys.stderr, 'Unable to do something: %s' % command

引发异常（traceback）省略）：

The exception is raised (traceback omitted):

IOError: [Errno 5] Input/output error

对于上下文，这通常是当时较大的函数尝试做的事情：

For context, this is generally what the larger function is trying to do at the time:

from subprocess import Popen, PIPE
import sys
def run_commands(commands):
    for command in commands:
        try:
            out, err = Popen(command, shell=True, stdout=PIPE, stderr=PIPE).communicate()
            print >> sys.stdout, out
            if err:
                raise Exception('ERROR -- an error occurred when executing this command: %s --- err: %s' % (command, err))
        except:
            print >> sys.stderr, 'Unable to do something: %s' % command
run_commands(["ls", "echo foo"])

>> 语法对我来说并不是特别熟悉，这不是我经常使用的东西，我知道它是也许是写给stderr的最不喜欢的方式。但是我不相信替代方案会解决潜在的问题。

The >> syntax is not particularly familiar to me, it's not something I use often, and I understand that it is perhaps the least preferred way of writing to stderr. However I don't believe the alternatives would fix the underlying problem.

从我读过的文档来看，IOError 5经常被误用，并且有些松散定义，运行不同使用它来覆盖不同问题的系统。在我的例子中我能看到的最好的是python进程不再附加到终端/ pty。

From the documentation I have read, IOError 5 is often misused, and somewhat loosely defined, with different operating systems using it to cover different problems. The best I can see in my case is that the python process is no longer attached to the terminal/pty.

最好的我什么也说不出来是将进程与stdout / stderr流 - 例如，终端仍处于打开状态，所有内容看起来都很好。这可能是由于子流程以不洁的方式终止而造成的吗？还有什么可能是导致这个问题的原因 - 或者我可以引入哪些其他步骤来进一步调试它？

As best I can tell nothing is disconnecting the process from the stdout/stderr streams - the terminal is still open for example, and everything 'appears' to be fine. Could it be caused by the child process terminating in an unclean fashion? What else might be a cause of this problem - or what other steps could I introduce to debug it further?

在处理异常方面，我显然能够抓住它，但我假设这意味着我将无法打印到stdout / stderr执行剩余的工作？我可以以某种方式重新连接到这些流 - 可能通过将 sys.stdout 重置为 sys .__ stdout __ 等？在这种情况下，不能写入stdout / stderr不被认为是致命的，但如果它表明出现了问题，我宁愿提前保释。

In terms of handling the exception, I can obviously catch it, but I'm assuming this means I wont be able to print to stdout/stderr for the remainder of execution? Can I reattach to these streams somehow - perhaps by resetting sys.stdout to sys.__stdout__ etc? In this case not being able to write to stdout/stderr is not considered fatal but if it is an indication of something starting to go wrong I'd rather bail early.

我想最终我有点不知道从哪里开始调试这个......

I guess ultimately I'm at a bit of a loss as to where to start debugging this one...

推荐答案

我认为它与进程附加的终端有关。当我在后台运行python进程并关闭我启动它的终端时出现此错误：

I think it has to do with the terminal the process is attached to. I got this error when I run a python process in the background and closed the terminal in which I started it:

$ myprogram.py
Ctrl-Z
$ bg
$ exit

问题是我在远程服务器中启动了一个未守护进程并注销（关闭终端会话）。解决方案是在远程服务器上启动screen / tmux会话，并在此会话中启动该进程。然后分离会话+注销会使终端与进程保持关联。这至少在* nix世界中起作用。

The problem was that I started a not daemonized process in a remote server and logged out (closing the terminal session). A solution was to start a screen/tmux session on the remote server and start the process within this session. Then detaching the session+log out keeps the terminal associated with the process. This works at least in the *nix world.

这篇关于打印时IOError输入/输出错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！