Hudson:“是:标准输出:管道破裂". [英] Hudson : "yes: standard output: Broken pipe"

问题描述

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

I need to run a shell script in hudson. That script needs an answer from the user. To give an automatic answer I did the following command line :  

yes | ./MyScript.sh

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

This works well in Ubuntu terminal. But when I use the same command in the Hudson job, the script will be automated and do all the needed work, but at the end, I get these two lines of error :

yes: standard output: Broken pipe
yes: write error

这会导致我的哈德森工作失败.

And this causes the failure to my Hudson job.

我应该如何更改命令行以使其在Hudson中正常工作?

How should I change my command line to work well in Hudson?

推荐答案

但是您如何解释我在本地运行脚本 时没有收到此错误，但是从Hudson作业远程运行时却收到了错误?

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已经退出时，它试图写入管道.

When you are running it in a terminal (locally); yes is killed by SIGPIPE signal that is generated when it tries to write to the pipe when MyScript.sh has already exited.

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

Whatever runs the command (remotely) in Hudson traps that signal (set its handler to SIG_IGN, you can test it by running trap command and searching for SIGPIPE in the output) and it doesn't restore the signal for new child processes (yes and whatever runs MyScript.sh e.g., sh in your case). It leads to the write error (EPIPE) instead of the signal. yes detects the write error and reports it.

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

You can simply ignore the error message:

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

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

You could also report the bug against the component that runs the pipeline. The bug is in not restoring SIGPIPE to the default handler after the child is forked. It is what programs expect when they are run in a terminal on POSIX systems. Though I don't know whether there is a standard way to do it for a java-based program. jvm probably raises an exception for every write error so not-dying on SIGPIPE is not a problem for a java program.

哈德逊进程之类的守护程序通常会忽略SIGPIPE信号.您不希望守护进程仅因为与您通信的进程死亡而死，并且无论如何都要检查写入错误.

It is common for daemons such as hudson process to ignore SIGPIPE signal. You don't want your daemon to die only because the process you are communicating with dies and you would check for write errors anyway.

被编写为要在终端上运行的普通程序不会检查每个printf()的状态是否有错误，但是您希望它们在流水线下游的程序终止时(例如，如果您运行source | sink流水线而终止)；通常，如果sink退出，您希望source进程尽快退出.

Ordinary programs that are written to be run in a terminal do not check status of every printf() for errors but you want them to die if programs down the pipeline die e.g., if you run source | sink pipeline; usually you want source process to exit as soon as possible if sink exits.

EPIPE写错误.因此它应该在接收到信号后就死掉了.

EPIPE write error is returned if SIGPIPE signal is disabled (as it looks like in hudson's case) or if a program does not die on receiving it (yes program does not defined any handlers for SIGPIPE so it should die on receiving the signal).

我不想忽略该错误，我想执行正确的命令或解决该错误的方法.

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

唯一的方式 yes进程停止如果它被杀死或遇到写错误.如果SIGPIPE信号被设置为(被父级)忽略，并且没有其他信号终止该进程，则yes在./MyScript.sh退出时收到写入错误.如果使用yes程序，则没有其他选择.

the only way yes process stops if it is killed or encountered a write error. If SIGPIPE signal is set to be ignored (by the parent) and no other signal kills the process then yes receives write error on ./MyScript.sh exit. There are no other options if you use yes program.

SIGPIPE信号和EPIPE错误传达了完全相同的信息-管道损坏.如果为yes进程启用了SIGPIPE，则不会看到该错误.只是因为你看到了它；没有新的事情发生.这仅表示./MyScript.sh退出(成功或失败-无关紧要).

SIGPIPE signal and EPIPE error communicate the exact same information -- pipe is broken. If SIGPIPE were enabled for yes process then you wouldn't see the error. And only because you see it; nothing new happens. It just means that ./MyScript.sh exited (successfully or unsuccessfully -- doesn't matter).

这篇关于Hudson:“是:标准输出:管道破裂".的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！