壊れたパイプはJenkinsにのみ表示されます。

壊れたパイプはJenkinsにのみ表示されます。

ローカルでうまく動作するスクリプトがあります。しかし、Jenkinsで実行するとError: writing output failed: Broken pipe

私の質問は、Jenkinsで動作するようにこの問題を解決する方法です。

それでは、この質問に答えるために状況を活用してみましょう。実際のパイプラインはsomevar=$(jq --arg host "${HOSTNAME}" --arg id "${ID}"'.[] | select((.hostname==$host) and (.port==XXXX)).serviceId = $id' <<<"${MYJSON}" | jq -s)

ジェンキンスバージョン2.164.3

Jenkins Bash バージョン 4.2

Jenkins オペレーティングシステム CentOS 7

ローカルバッシュバージョン5

基本オペレーティングシステム Arch カーネルバージョン 5.0

また、次の仕様のDockerコンテナでこのスクリプトを正常に実行しました。

コンテナオペレーティングシステムUbuntu 18.04

バッシュ 4.4

したがって、私の質問に答えることができない場合は、これが他の環境では機能しますが、Jenkinsでは機能しない理由を説明できます。それともこの問題に対する解決策を提案できますか?現在、trapより多くの情報を得るために使用を検討していますか?しかし、どうすればよいかわかりません。

答え1

スクリプトを呼び出すプログラムを探し、シグナルハンドラを無視SIGPIPEするように設定します。 (検索trap '' PIPEなど)。信号の「無視」処理は子プロセスに継承されます。

同様のパイプでは、... | head -5パイプの左側がきれいで静かに抜け出すのはSIGPIPE絶対に正常です。無視または捕捉されると、SIGPIPEシステムwrite()コールはエラーを返すEPIPEか、「壊れたパイプ」に翻訳されます。

多くの不都合なプログラムは、aが成功したことを確認しませんwrite()。つまり、SIGPIPEsetuid実行可能ファイルを呼び出すときに無視するように設定すると、攻撃パスになる可能性があります。

しかし、そうではありません。jq予期しない状況が発生した場合はすぐにお知らせします(出力に差がない可能性が高い)。

しかし、私はJenkinsを使うことも好きでもないので、もう助けることはできません。私はこれがJenkinsのせいであるかどうかとても疑います。

関連情報