docker exec in stopped containers

[yajo]

Description

Currently there's no way to execute an arbitrary command in a stopped container.

Although this is by design right now, this design presents one problem: you cannot inspect a container whose build failed straight away.

Steps to reproduce the issue:

1. docker build --tag some-failing-image .
2. The build stops.
3. docker ps -a shows that the container that failed is called pensive_fermi.
4. OK, I want to check what happened there to fix the Dockerfile: docker exec pensive_fermi sh.

Describe the results you received:
Error response from daemon: Container a212058e9a8bf7354c63bf293481c96a22d91e97fcd4c43421a99c9eb328cf1c is not running

Describe the results you expected:
docker exec should have a --boot (or similar) flag that let you boot the container with this command if it is stopped, or docker start should let you pass a new command when restarting it.

Additional information you deem important (e.g. issue happens only occasionally):

Possible workarounds/drawbacks:

• use volumes and mount them in a new container. Problem: if problem happened outside the volume.
• If original container was started with bash, sleep or anything like that, you can docker start it and then docker exec it. Problem: what if not? What if the command simply fails and exits straight away?
• Do this:

  docker commit pensive_fermi temp
  docker run -it --rm temp <your commands>
  docker rmi temp
  

  It should work, although it's not very straightforward nor documented. However, I guess that documenting this could be considered a fix.

Output of docker version:

$ docker version
Client:
 Version:         1.12.6
 API version:     1.24
 Package version: docker-common-1.12.6-5.git037a2f5.fc25.x86_64
 Go version:      go1.7.4
 Git commit:      037a2f5/1.12.6
 Built:           Wed Jan 18 12:11:29 2017
 OS/Arch:         linux/amd64

Server:
 Version:         1.12.6

 API version:     1.24
 Package version: docker-common-1.12.6-5.git037a2f5.fc25.x86_64
 Go version:      go1.7.4
 Git commit:      037a2f5/1.12.6
 Built:           Wed Jan 18 12:11:29 2017
 OS/Arch:         linux/amd64

Output of docker info:

$ docker info
Containers: 114
 Running: 0
 Paused: 0
 Stopped: 114
Images: 1635
Server Version: 1.12.6
Storage Driver: overlay2
 Backing Filesystem: extfs
Logging Driver: journald
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: oci runc
Default Runtime: oci
Security Options: seccomp
Kernel Version: 4.9.4-201.fc25.x86_64
Operating System: Fedora 25 (Workstation Edition)
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 2
CPUs: 4
Total Memory: 6.761 GiB
Name: yajolap.yajodomain
ID: KUBN:F7JL:URX6:HO55:R3L2:SCUU:IWVY:EZ2O:F53G:WHTO:3G4D:R4YU
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
Insecure Registries:
 127.0.0.0/8
Registries: docker.io (secure)

Additional environment details (AWS, VirtualBox, physical, etc.):
local linux

[thaJeztah]

docker logs and docker inspect on a stopped container should still be possible, but docker exec indeed not.

ping @crosbymichael @mlaventure IIRC, RunC had an option to exec into a stopped container? Is this something that could be done, or not?

[mlaventure]

@yajo Normally the image of the last step that failed still exist, you can docker --rm <id> sh it and try the step anew:

e.g.:

 ---> 664909d2bea2
Removing intermediate container d8196abc299d
Step 3/3 : RUN toto
 ---> Running in dae281b60781
/bin/sh: toto: not found
The command '/bin/sh -c toto' returned a non-zero code: 127
# docker run --rm -ti 664909d2bea2 sh

[yajo]

Maybe that's an option... I guess if the hashes said what they are, it would be easier to guess that:

---> Image 664909d2bea2
Removing intermediate container d8196abc299d
Step 3/3 : RUN toto
 ---> Running in container dae281b60781
/bin/sh: toto: not found
The command '/bin/sh -c toto' returned a non-zero code: 127
# docker run --rm -ti 664909d2bea2 sh

In any case, that still counts as workaround IMHO.

[303248153]

I strongly agree docker should support start a stopped container with custom command, it could make debug easier.
I have to used docker export with tar -xf every time until I saw the workaround.

[0xdevalias]

Related workaround: #18078 (comment)

FWIW, I would also love a 'built in' way to do this, rather than having to script around it, even if all it ends up doing is the above.

[Chealer]

Until there's a good way to do this, users can be pointed to this document, which explains well the problem and its workaround.

[thaJeztah]

@Chealer looks like the same as was linked in the comment above yours;

Related workaround: #18078 (comment)