moby: exec not running

Description docker exec -i -t <container_id> bash the above command giving me error that the image has run and stopped, but my image is still running.

Error: rpc error: code = 13 desc = invalid header field value "oci runtime error: exec failed: cannot exec a container that has run and stopped\n"

I am running the Airflow Image from this place docker pull puckel/docker-airflow

I ran the Image with below command from simple-docker-ui-app docker run -i -t -P --name airflow puckel/docker-airflow:latest docker-compose -f docker-compose-LocalExecutor.yml up -d

Steps to reproduce the issue:

start the docker image
run below command docker exec -i -t <container_id> bash

Describe the results you received:

Describe the results you expected:

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

Output of docker version:

Client:
 Version:      1.12.2
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   bb80604
 Built:        
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.2
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   bb80604
 Built:        
 OS/Arch:      linux/amd64

Output of docker info:

(paste your output here)

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

About this issue

Original URL
State: closed
Created 8 years ago
Reactions: 7
Comments: 29 (19 by maintainers)

Commits related to this issue

Fix issue in `GetProcessStartTime` This fix tries to address the issue raised in docker: https://github.com/docker/docker/issues/27540 The issue was that `GetProcessStartTime` use space `" "` to sp... — committed to docker-archive/runc by yongtang 8 years ago

Most upvoted comments

This still seems to be an issue in 1.12.6.

docker exec -it kickass_volhard /bin/bash
rpc error: code = 2 desc = containerd: container not started

I get the above on 2 different machines running same version of ubuntu (16.10) and same version of docker. Also same behavior regardless of container (i.e. happens for all containers running on the machines).

docker info
Containers: 2
 Running: 2
 Paused: 0
 Stopped: 0
Images: 2
Server Version: 1.12.6
Storage Driver: overlay
 Backing Filesystem: extfs
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
 Volume: local
 Network: bridge host null overlay
Swarm: inactive
Runtimes: runc
Default Runtime: runc
Security Options: apparmor seccomp
Kernel Version: 4.8.0-41-generic
Operating System: Ubuntu 16.10
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.953 GiB
Name: prometheus01
ID: PVPE:VSEF:WIZD:PP7V:MZJC:E4BR:ME2H:PLUB:HKF6:AS5E:AFQV:YHZR
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No swap limit support
Insecure Registries:
 127.0.0.0/8

# docker version
Client:
 Version:      1.12.6
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   78d1802
 Built:        Tue Jan 31 23:47:34 2017
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.6
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   78d1802
 Built:        Tue Jan 31 23:47:34 2017
 OS/Arch:      linux/amd64

ghost on Apr 13, 2017

Fixed by https://github.com/docker/docker/pull/27610

vieux on Oct 24, 2016

Ok so https://github.com/opencontainers/runc/pull/1136 does fix this issue. The regression is that we call container.Status() on exec, state, etc in runc with the vendored version that was included in 1.12.2.

The problem is that the parsing logic did not account for the space inside the (). The bug was not a regression but a long standing issue that was always there just uncovered by the fact that when we try to exec, we check that status, which in turn, reads the process start time to verify we are interacting with the process that we thought we were. This failed parsing so runc thinks that this is not the same process and the container was stopped. @yongtang 's pr fixes this and I verified the fix with docker.

crosbymichael on Oct 20, 2016

Can anyone summarize the final solution for this issue? I tried following the entire conversation but couldn’t resolve my issue.

krunalvora on Feb 24, 2017

@DEVELByte reverting to 1.12.1 fixes the issue for me, you might want to do that until we release a fix.

justincormack on Oct 20, 2016

I can confirm having the same problem after having upgraded to 1.12

Nearhan on Oct 19, 2016