0

I have a script that works just fine locally. But when I run it in Jenkins, I get Error: writing output failed: Broken pipe.

My question is how can I fix this to work in jenkins?

Now for the context to help answer the question. The actual pipe is somevar=$(jq --arg host "${HOSTNAME}" --arg id "${ID}"'.[] | select((.hostname==$host) and (.port==XXXX)).serviceId = $id' <<<"${MYJSON}" | jq -s).

Jenkins version 2.164.3

Jenkins bash version 4.2

Jenkins OS CentOS 7

Local bash version 5

Local OS Arch Kernel version 5.0

I have also successfully run this script in a docker container just fine with the following specs;

Container OS Ubuntu 18.04

Bash 4.4

So if you can not answer my question, maybe you can shed some light as to why this may work in other environments but not from Jenkins. Or maybe you can suggest ways to troubleshoot this? I'm currently thinking of using trap to get more information? But I'm not sure exactly how I can do this.

1

Go and find which of the programs which invoke your script is setting the SIGPIPE signal handler to ignore. (look for trap '' PIPE, etc). An "ignore" disposition of a signal is inherited by child processes.

In any pipeline like ... | head -5 it's absolutely normal that the left side of the pipeline get a SIGPIPE and exit cleanly and silently because of it. If it ignores or catches the SIGPIPE, a write() syscall will return with a EPIPE error, or translated, "Broken pipe".

Many crappy programs do not check if a write() succeeds -- which means that setting SIGPIPE to ignore may be an attack vector when invoking setuid executables.

But this is not the case of jq, which duly informs you of the unexpected conditition (which, most probably, would not make its output different).

But I don't use or like Jenkins, so I cannot help you further. Though I highly doubt that this is Jenkins' fault.

  • Thank you for your response @pizdelect. You are likely not entirely wrong. I am not as familiar with how to handle and manipulate signals as you are. I tried doing as you suggested, but not entirely sure I was doing it correctly. Eventually though I found the issue. For anyone else who may come along. CentOS 7 (which ran the script that failed) has jq 1.5 installed. I'm using jq 1.6 locally. There is something about pipeing to jq -s in 1.5 that it does not like. Even though the json being piped to it is valid. – Byron Mansfield Jun 11 at 17:56
  • Nope, you've just slightly changed the conditions, which has hidden rather than fixed the bug. FWIW a) "Broken pipe" can only happen when the SIGPIPE is caught or ignored and b) letting other processes inherit an ignored SIGPIPE disposition is always a bug (or an exploit ;-)). These are not speculations, feel free to ignore at your own risk. – pizdelect Jun 12 at 1:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.