`docker exec $CID false' does not set exit value to 1

[gdm85]

I am experiencing a weird issue with 1.3: exit value is always 0, regardless of command executed.

For example, running this script:

#!/bin/bash
CID=test-ev
docker run -d --name=$CID ubuntu:14.04 sh -c 'exec sleep 6000' || exit $?
docker exec $CID false
echo "docker exec: Exit value is $? (1 expected)"

The output is:

7e57bd4a32c168fc8ed9f23ef80737727984bbc4a8587d323109a2a5a53cef67
docker exec: Exit value is 0 (1 expected)

To verify that this problem is Docker-only, make same test with ssh or nsenter (my fork), that correctly return exit value 1.

I am right now looking up the code, as I have some clues about what could be happening, and will report later.

Update: I am using native driver. The log correctly reports the exit status:

[debug] exec.go:282 Exec task in container 4f555c8486f503fbfa8509f18c6f0fb17759b6d1161fc5f8b8ad7e8facc72bb1 exited with code 1

Update 2: I realize this is more a feature request rather than a bug: the "exec" operation is successful, but I believe users expect docker cli to fail with same exit code as container's process

[gdm85]

I found why the exit code is not 1: to do this you would have to reengineer the engine.Handler or engine.Status types to allow a payload.

Alternatives? An option to export the exit code to an environment variable (on host)?

I am sorry but as it is it's not much usable (without other hacks) and I actually will keep using nsenter

[SvenDowideit]

see https://groups.google.com/forum/#!topic/docker-user/IUB-PWldgU4 too

[gdm85]

@SvenDowideit thanks for cross-linking it :)

It will take a bit of efforts to create a pull request, as first it's needed to refactor how the engine handles results. I am not writing one at the moment, both because I can use nsenter and because I was waiting for more Docker developers feedback.

[LK4D4]

We have similar code for run. We need to implement some more endpoints for exec, which is not very hard, but very boring.

[irachex]

+1 docker exec should proxy exit code

[mkoval]

+1. Has anyone found a good workaround for this in the meantime? Is the docker-enter command provided by nsenter, linked to by @gdm85, effectively a drop-in replacement?

[gdm85]

@mkoval I use that as an SSH-like drop-in replacement, and I better customized the shell environment second my needs

[dougrad]

+1

[juniartisu]

Is this exec return code always 0 works now?
If so where can I get the fix? Thanks.