Docker return codes from background commands

I’m not getting the return code I expect, when executing a script inside a Docker container with a background task run in it.

This example docker file highlights the problem:

  • Rename file in docker container
  • Running Lightttpd in Docker: ulimits not honored
  • Running non-www stuff on an Elastic Beanstalk Docker container
  • docker error when called from network
  • Docker init Daemon best practices (PID 1 zombie reaping)
  • Bash script wait depended commands processes
  • FROM ubuntu:latest
    MAINTAINER Jakob H. Thomsen (jakob@gedefar.dk)
    
    RUN echo "#!/bin/bash\nset -e\n\nls / &\nexit 1" > /start_script.sh
    RUN chmod +x /start_script.sh 
    

    It creates the following file /start_script.sh inside the container:

    #!/bin/bash
    set -e
    
    ls / &
    exit 1
    

    So running docker build -t jakob/test . and docker run jakob/test cat /start_script.sh you would expect the return code to be 1, because of the exit 1. It is not, it is 0 and it is somehow because of the ls / & (if you remove that command you get the expected return code of 1).

    So my question is why ls / & overrides the return code of the exit 1 command? I tried making exit 1 to run in the background, but it doesn’t change the return code…

    As I’m using the setup to run Ruby specs, I’m really dependent upon the return code of the last command, so is there something I can do to make Docker return the return code of the last command?

    Thanks and I hope you can help, as it has taking me a loong time to pinpoint the exact issue of these ‘wrong’ return codes.

  • Spring Cloud Data Flow on Docker?
  • Docker workflow design with Jenkins on production
  • How to use Docker to make releases?
  • How to restart kubernetes Pods?
  • Stage, release and production server docker containers in single VPS
  • How do I use the public swagger-generator docker image to generate a client?
  • One Solution collect form web for “Docker return codes from background commands”

    Turned out that the issue is fixed in the newest version of Docker: https://github.com/dotcloud/docker/issues/3775

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.