New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docker commands should return nonzero error codes on failure #354

Closed
cespare opened this Issue Apr 8, 2013 · 16 comments

Comments

Projects
None yet
@cespare
Contributor

cespare commented Apr 8, 2013

It would be good to do an audit of each command and ensure that all failure modes result in a nonzero exit status code.

I just noticed that a failed pull has a 0 exit status.

$ docker pull foo/bar
Pulling repository foo/bar
Error: HTTP code: 404
$ echo $?
0

This is important when you're trying to use docker programmatically. It's not great to have to search for error messages in the output.

@sa2ajj

This comment has been minimized.

Show comment
Hide comment
@sa2ajj

sa2ajj Apr 8, 2013

Contributor

👍

Contributor

sa2ajj commented Apr 8, 2013

👍

@brejoc

This comment has been minimized.

Show comment
Hide comment
@brejoc

brejoc Apr 11, 2013

+1 This is really super important!

brejoc commented Apr 11, 2013

+1 This is really super important!

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 11, 2013

Collaborator

Agree. The culprit is rcli, our overly simple tcp protocol. A proper remote
API will fix this.

(For the same reason the client can't differentiate stdout from stderr on
attach)

On Thursday, April 11, 2013, Jochen Breuer wrote:

+1 This is really super important!


Reply to this email directly or view it on GitHubhttps://github.com//issues/354#issuecomment-16223703
.

Collaborator

shykes commented Apr 11, 2013

Agree. The culprit is rcli, our overly simple tcp protocol. A proper remote
API will fix this.

(For the same reason the client can't differentiate stdout from stderr on
attach)

On Thursday, April 11, 2013, Jochen Breuer wrote:

+1 This is really super important!


Reply to this email directly or view it on GitHubhttps://github.com//issues/354#issuecomment-16223703
.

@JeanMertz

This comment has been minimized.

Show comment
Hide comment
@JeanMertz

JeanMertz Apr 13, 2013

Does this also affect regular status code from commands run in a container? (it seems like it).

For example:

$ docker run base /bin/sh -c 'exit 1'
2013/04/13 11:49:43 docker run base /bin/sh -c exit 1
$ echo $?
0

I can understand that technically, the docker process exited correctly, so it should return 0, but is there some other way to get the exit code of the command itself?

JeanMertz commented Apr 13, 2013

Does this also affect regular status code from commands run in a container? (it seems like it).

For example:

$ docker run base /bin/sh -c 'exit 1'
2013/04/13 11:49:43 docker run base /bin/sh -c exit 1
$ echo $?
0

I can understand that technically, the docker process exited correctly, so it should return 0, but is there some other way to get the exit code of the command itself?

@sa2ajj

This comment has been minimized.

Show comment
Hide comment
@sa2ajj

sa2ajj Apr 13, 2013

Contributor

Probably in this case, some existing practices (like chroot) could be employed here?

(A quote from Linux' chroot info page)

     chroot OPTION NEWROOT [COMMAND [ARGS]...]

...

   Exit status:

     125 if `chroot' itself fails
     126 if COMMAND is found but cannot be invoked
     127 if COMMAND cannot be found
     the exit status of COMMAND otherwise
Contributor

sa2ajj commented Apr 13, 2013

Probably in this case, some existing practices (like chroot) could be employed here?

(A quote from Linux' chroot info page)

     chroot OPTION NEWROOT [COMMAND [ARGS]...]

...

   Exit status:

     125 if `chroot' itself fails
     126 if COMMAND is found but cannot be invoked
     127 if COMMAND cannot be found
     the exit status of COMMAND otherwise
@brejoc

This comment has been minimized.

Show comment
Hide comment
@brejoc

brejoc Apr 13, 2013

Catching a return value inside the container would be great, but I think that wouldn't be so easy. What value would be used? There could be a whole series of commands executed inside of the container. Which one would be chosen for docker to return? Don't know how this could be implemented in a useful way.

brejoc commented Apr 13, 2013

Catching a return value inside the container would be great, but I think that wouldn't be so easy. What value would be used? There could be a whole series of commands executed inside of the container. Which one would be chosen for docker to return? Don't know how this could be implemented in a useful way.

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 14, 2013

Collaborator

Actually, by design Docker only allows you to execute one command per
container - and it already stores its exit status. You can find it with
"docker inspect ID", or with "docker wait ID".

On Sat, Apr 13, 2013 at 1:44 PM, Jochen Breuer notifications@github.comwrote:

Catching a return value inside the container would be great, but I think
that wouldn't be so easy. What value would be used? There could be a whole
series of commands executed inside of the container. Which one would be
chosen for docker to return? Don't know how this could be implemented in a
useful way.


Reply to this email directly or view it on GitHubhttps://github.com//issues/354#issuecomment-16340511
.

Collaborator

shykes commented Apr 14, 2013

Actually, by design Docker only allows you to execute one command per
container - and it already stores its exit status. You can find it with
"docker inspect ID", or with "docker wait ID".

On Sat, Apr 13, 2013 at 1:44 PM, Jochen Breuer notifications@github.comwrote:

Catching a return value inside the container would be great, but I think
that wouldn't be so easy. What value would be used? There could be a whole
series of commands executed inside of the container. Which one would be
chosen for docker to return? Don't know how this could be implemented in a
useful way.


Reply to this email directly or view it on GitHubhttps://github.com//issues/354#issuecomment-16340511
.

@sylvinus

This comment has been minimized.

Show comment
Hide comment
@sylvinus

sylvinus Nov 23, 2013

@shykes I still feel propagating the return code would be a very useful and more unix-y option to add to docker run, mostly when running one-off commands.

Currently if I'm not mistaken the return code is lost when using the -rm flag?

sylvinus commented Nov 23, 2013

@shykes I still feel propagating the return code would be a very useful and more unix-y option to add to docker run, mostly when running one-off commands.

Currently if I'm not mistaken the return code is lost when using the -rm flag?

@Cidan

This comment has been minimized.

Show comment
Hide comment
@Cidan

Cidan Nov 24, 2013

+1, propagating the return code of the command run would be insanely helpful, and it makes sense to do so.

Cidan commented Nov 24, 2013

+1, propagating the return code of the command run would be insanely helpful, and it makes sense to do so.

@vieux

This comment has been minimized.

Show comment
Hide comment
@vieux

vieux Nov 25, 2013

Collaborator

@sylvinus @Cidan we already fixed this master (at least I think so):

$> docker run busybox /bin/sh -c 'exit 17'
$> echo $?
17

This isn't working for you ?

Collaborator

vieux commented Nov 25, 2013

@sylvinus @Cidan we already fixed this master (at least I think so):

$> docker run busybox /bin/sh -c 'exit 17'
$> echo $?
17

This isn't working for you ?

@sylvinus

This comment has been minimized.

Show comment
Hide comment
@sylvinus

sylvinus Nov 26, 2013

Ah great, works indeed :) I think it was fixed in 0.6.7 then.

sylvinus commented Nov 26, 2013

Ah great, works indeed :) I think it was fixed in 0.6.7 then.

@mattwallington

This comment has been minimized.

Show comment
Hide comment
@mattwallington

mattwallington Dec 3, 2013

So the only problem is now when you pass an invalid endpoint path into docker run it returns a 0 which I use to tell me there was an issue with the docker run command.

mattwallington commented Dec 3, 2013

So the only problem is now when you pass an invalid endpoint path into docker run it returns a 0 which I use to tell me there was an issue with the docker run command.

@bkreider

This comment has been minimized.

Show comment
Hide comment
@bkreider

bkreider Feb 5, 2014

I'm still experiencing some weird return values using ENTRYPOINT (or CMD). I have a bash script that calls some other bash scripts. At the end of it I do an exit 1 for testing and about half the time the return value of docker run is 0. If i do: docker ps -a it says the return value was 1 for each of the runs. This only seems to happen if I run multiple commands in the bash script. A simple bash script that only calls exit 1 works fine.

I'm having trouble isolating the exact conditions that make this happen. Is there an easy way to easily get the return value without parsing yaml?

Update: The answer is something like this docker inspect -format='{{.State.ExitCode}}' <id>. I still don't know why run gives random return values.

Client version: 0.7.6
Go version (client): go1.2
Git commit (client): bc3b2ec
Server version: 0.7.6
Git commit (server): bc3b2ec
Go version (server): go1.2

bkreider commented Feb 5, 2014

I'm still experiencing some weird return values using ENTRYPOINT (or CMD). I have a bash script that calls some other bash scripts. At the end of it I do an exit 1 for testing and about half the time the return value of docker run is 0. If i do: docker ps -a it says the return value was 1 for each of the runs. This only seems to happen if I run multiple commands in the bash script. A simple bash script that only calls exit 1 works fine.

I'm having trouble isolating the exact conditions that make this happen. Is there an easy way to easily get the return value without parsing yaml?

Update: The answer is something like this docker inspect -format='{{.State.ExitCode}}' <id>. I still don't know why run gives random return values.

Client version: 0.7.6
Go version (client): go1.2
Git commit (client): bc3b2ec
Server version: 0.7.6
Git commit (server): bc3b2ec
Go version (server): go1.2
@tianon

This comment has been minimized.

Show comment
Hide comment
@tianon

tianon Feb 6, 2014

Member

@bkreider there were a bunch of exit code bugs fixed recently (ie, since 0.7.6 was released). Can you update to 0.8.0 and see if it resolves the inconsistencies?

Also, you might enjoy docker wait <id>, which just waits for the container to finish and then prints the exit code on stdout.

Member

tianon commented Feb 6, 2014

@bkreider there were a bunch of exit code bugs fixed recently (ie, since 0.7.6 was released). Can you update to 0.8.0 and see if it resolves the inconsistencies?

Also, you might enjoy docker wait <id>, which just waits for the container to finish and then prints the exit code on stdout.

@bkreider

This comment has been minimized.

Show comment
Hide comment
@bkreider

bkreider Feb 6, 2014

@tianon Thanks! I had just installed the latest yesterday. The 0.8.0 version seems to fix it. That's much easier than wrapping in a bash script like this:

docker run --name $name <id> &> /dev/null
ret=$(docker inspect -format='{{.State.ExitCode}}' $name)
docker rm $name
exit $ret

bkreider commented Feb 6, 2014

@tianon Thanks! I had just installed the latest yesterday. The 0.8.0 version seems to fix it. That's much easier than wrapping in a bash script like this:

docker run --name $name <id> &> /dev/null
ret=$(docker inspect -format='{{.State.ExitCode}}' $name)
docker rm $name
exit $ret
@rutsky

This comment has been minimized.

Show comment
Hide comment
@rutsky

rutsky Mar 12, 2014

Contributor

All non-zero exit codes are mapped to 255 for me in 0.8.1, is this correct behavior?
This differs with example provided by @vieux :

$ docker run busybox /bin/sh -c 'exit 17'
$ echo $?
255
$ docker run busybox /bin/sh -c 'exit 132'
$ echo $?
255
$ docker run busybox /bin/sh -c 'exit 0'
$ echo $?
0
$ docker --version
Docker version 0.8.1, build a1598d1

EDIT:
Nevermind. After upgrading to 0.9.0 exit code as expected.

Contributor

rutsky commented Mar 12, 2014

All non-zero exit codes are mapped to 255 for me in 0.8.1, is this correct behavior?
This differs with example provided by @vieux :

$ docker run busybox /bin/sh -c 'exit 17'
$ echo $?
255
$ docker run busybox /bin/sh -c 'exit 132'
$ echo $?
255
$ docker run busybox /bin/sh -c 'exit 0'
$ echo $?
0
$ docker --version
Docker version 0.8.1, build a1598d1

EDIT:
Nevermind. After upgrading to 0.9.0 exit code as expected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment