shell - hudson : "yes: standard output: Broken pipe"

Question

我需要在 hudson 中运行一个 shell 脚本。该脚本需要用户的回答。为了给出自动回答，我执行了以下命令行:

yes | ./MyScript.sh

这在 Ubuntu 终端中运行良好。但是当我在 Hudson 作业中使用相同的命令时，脚本将自动执行并完成所有需要的工作，但最后，我得到了这两行错误:

yes: standard output: Broken pipe
yes: write error

这导致我在 Hudson 的工作失败。

我应该如何更改我的命令行才能在 Hudson 中正常工作？

Answer 1

But how would you explain that I dont get this error while running the script locally, but I get the error when running it remotely from a Hudson job?

当您在终端中运行它时(本地)； yes被SIGPIPE杀死MyScript.sh 时尝试写入管道时生成的信号已经退出了。

无论在 Hudson 中运行命令(远程)都会捕获该信号(将其处理程序设置为 SIG_IGN ，您可以通过运行 trap 命令并在输出中搜索 SIGPIPE 来测试它)和它不会恢复新子进程的信号( yes 和任何运行 MyScript.sh 的信号，例如，在您的情况下为 sh )。它导致写入错误(EPIPE)而不是信号。 yes检测写入错误并报告。

您可以简单地忽略错误信息:

yes 2>/dev/null | ./MyScript.sh

您还可以针对运行管道的组件报告错误。该错误在于在 fork 子进程后未将 SIGPIPE 恢复为默认处理程序。这是程序在 POSIX 系统的终端中运行时所期望的。虽然我不知道对于基于 java 的程序是否有标准的方法来做到这一点。 jvm可能会为每个写入错误引发异常，因此在 SIGPIPE 上不死对 Java 程序来说不是问题。

像 hudson 进程这样的守护进程忽略 SIGPIPE 信号是很常见的。您不希望您的守护进程仅仅因为与您通信的进程终止而终止，并且无论如何您都会检查写入错误。

编写为在终端中运行的普通程序不会检查每个 printf() 的状态对于错误，但你希望它们在流水线中的程序死掉时死掉，例如，如果你运行 source | sink管道;通常你想要source如果sink，进程尽快退出导出。

EPIPE如果 SIGPIPE 则返回写入错误信号被禁用(就像 hudson 的情况一样)或者如果程序没有在接收到它时死掉(yes 程序没有为 SIGPIPE 定义任何处理程序，所以它应该在接收到信号时死掉)。

I don't want to ignore the error, I want to do the right command or fix to get rid of the error.

唯一方式 yes process stops if it is killed or encountered a write error .如果SIGPIPE信号被设置为忽略(由父级)，然后没有其他信号终止进程 yes在 ./MyScript.sh 上收到写入错误导出。如果您使用 yes，则没有其他选项程序。

SIGPIPE信号和 EPIPE错误传达完全相同的信息——管道坏了。如果SIGPIPE为 yes 启用process 然后你就不会看到错误。只是因为你看到了；没有新的事情发生。这只是意味着 ./MyScript.sh退出(成功或不成功——无关紧要)。