Details
-
Bug
-
Status: Reopened (View Workflow)
-
Minor
-
Resolution: Unresolved
-
None
-
jenkins 2.11, gerrit-trigger 2.21.1, docker-workflow 1.5, pipeline 2.2
Description
So I'm trying to use workflow and gerrit-trigger plugins together. But I'm getting script returned exit code -1. I've checked, and it's not 'git fetch' network related issue or anything like that. Any command I run through 'sh' which make some output delay like, git fetch or clone, or whatever - gives me -1 exit code. Groovy script is same like in gerrit-trigger example from https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+Trigger
My log samples below:
Retriggered by user admin for Gerrit: https://url/gerrit/73010 in silent mode.
[Pipeline] node
Running on master in /var/jenkins_home/workspace/pipeline-docker-test
[Pipeline] {
[Pipeline] withDockerServer
[Pipeline] {
[Pipeline] sh
[pipeline-docker-test] Running shell script
+ docker inspect -f . dockers.local:5000/image:latest
.
[Pipeline] withDockerContainer
$ docker run -t -d -u 1000:1000 -w /var/jenkins_home/workspace/pipeline-docker-test -v /var/jenkins_home/workspace/pipeline-docker-test:/var/jenkins_home/workspace/pipeline-docker-test:rw -v /var/jenkins_home/workspace/pipeline-docker-test@tmp:/var/jenkins_home/workspace/pipeline-docker-test@tmp:rw -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** -e ******** dockers.local:5000/image:latest cat
[Pipeline] {
[Pipeline] stage (cloning repo)
Entering stage cloning repo
Proceeding
[Pipeline] git
> git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
> git config remote.origin.url ssh://url:29418/project # timeout=10
Fetching upstream changes from ssh://url:29418/project
> git --version # timeout=10
> git -c core.askpass=true fetch --tags --progress ssh://url:29418/project +refs/heads/*:refs/remotes/origin/*
> git rev-parse refs/remotes/origin/master^{commit} # timeout=10
> git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision 82beb7889ae2fea7a35a59575bb849c881302eec (refs/remotes/origin/master)
> git config core.sparsecheckout # timeout=10
> git checkout -f 82beb7889ae2fea7a35a59575bb849c881302eec # timeout=10
> git branch -a -v --no-abbrev # timeout=10
> git branch -D master # timeout=10
> git checkout -b master 82beb7889ae2fea7a35a59575bb849c881302eec
> git rev-list 82beb7889ae2fea7a35a59575bb849c881302eec # timeout=10
[Pipeline] stage (Checkout patchset)
Entering stage Checkout patchset
Proceeding
[Pipeline] sh
[pipeline-docker-test] Running shell script
+ git fetch origin refs/changes/10/73010/1:change-73010-1
[Pipeline] }
$ docker stop d3499aacbbef9d2acbb0e9cdbac51c0ea620e91b9893d46ceda49d5344357c61
$ docker rm -f d3499aacbbef9d2acbb0e9cdbac51c0ea620e91b9893d46ceda49d5344357c61
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // withDockerServer
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code -1
Finished: FAILURE
Example below. I made 3 'sh' steps:
sh 'pwd' sh 'sleep 1' sh 'uname'
and log:
[Pipeline] {
[Pipeline] sh
[pipeline-docker-test] Running shell script
+ pwd
/var/jenkins_home/workspace/pipeline-docker-test
[Pipeline] sh
[pipeline-docker-test] Running shell script
+ sleep 1
[Pipeline] }
$ docker stop 93ea34143c0a9c7e28b6e580d620f33bcc8f0e0081e7885ea63ef9ad0d1fc57e
$ docker rm -f 93ea34143c0a9c7e28b6e580d620f33bcc8f0e0081e7885ea63ef9ad0d1fc57e
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // withDockerServer
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code -1
Finished: FAILURE
Attachments
Issue Links
- duplicates
-
JENKINS-47791 Eliminate ProcessLiveness
-
- Resolved
-
- is duplicated by
-
-
- Resolved
-
- relates to
-
-
- Open
-
-
-
- Resolved
-
-
-
- In Review
-
Activity
I'm seeing this issue in Jenkins ver. 2.63. I am running a python script inside a docker container and getting:
...
[Pipeline] stage
[Pipeline] { (Publish Classes)
[Pipeline] sh
[***] Running shell script
+ ./post_classes.py
...
ERROR: script returned exit code -1
Finished: FAILURE
I've tried to reproduce it with a simpler script, but I can't. It happens only with certain builds.
Update:
The docker container I was building didn't contain ps (thank you iiosifidis for your message above). After adding ps, it fixed the issue.
Cosmin Stroe
added a comment - - edited I'm seeing this issue in Jenkins ver. 2.63. I am running a python script inside a docker container and getting:
...
[Pipeline] stage
[Pipeline] { (Publish Classes)
[Pipeline] sh
[***] Running shell script
+ ./post_classes.py
...
ERROR: script returned exit code -1
Finished: FAILURE
I've tried to reproduce it with a simpler script, but I can't. It happens only with certain builds.
Update:
The docker container I was building didn't contain ps (thank you iiosifidis for your message above). After adding ps, it fixed the issue. I had the same issue，and I had checked my docker container，“ps” command can run in it，so I thought it had no relation with the cmmand “ps” installed in docker image，any other solutions？
I had the same issue in my build where a Jenkins container, is running a Jenkinsfile which in turn runs commands inside another container, based on the latest ubuntu one, with the withDockerContainer or docker.image.inside command. A script that would take a few minutes checking out some git repositories would prematurely end with the ERROR: script returned exit code -1.
There is some discussion in Stackoverflow where it is mentioned that this issue is related with ps not installed in the container you want to run commands inside in. Indeed manually running my container with docker exec -it mycontainer bash, I noticed that running ps was failing with a command not found. I am not sure what the exact connection is but I can confirm that adding apt-get install -y procps in the Dockerfile of the container that I want to run commands inside, solved that issue for me, at least as a temporary workaround.