Sometimes a docker container gets stuck so that it can't be stopped or removed

[deiga]

CONTAINER ID        IMAGE                            COMMAND                CREATED             STATUS              PORTS                                                NAMES
1fb364265a92        mediit/mongodb:stage             "mongod"               22 minutes ago      Up 22 minutes       0.0.0.0:49195->27017/tcp, 0.0.0.0:49196->28017/tcp   mongodb

$ docker stop mongodb
Error response from daemon: Cannot stop container mongodb: no such process
FATA[0000] Error: failed to stop one or more containers

$ docker rm -f mongodb
Error response from daemon: Could not kill running container, cannot remove - no such process
FATA[0001] Error: failed to remove one or more containers

$ docker info
Containers: 14
Images: 178
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Dirs: 206
Execution Driver: native-0.2
Kernel Version: 3.13.0-32-generic
Operating System: Ubuntu 14.04.1 LTS
CPUs: 2
Total Memory: 7.704 GiB
Name: medi-it-sote
ID: GGAU:OQIH:U6ZI:TOEP:G3JX:Z5WA:D5WQ:CFPA:NLMB:F6P5:IR7I:2GTC
WARNING: No swap limit support

$ docker version
Client version: 1.4.1
Client API version: 1.16
Go version (client): go1.3.3
Git commit (client): 5bc2ff8
OS/Arch (client): linux/amd64
Server version: 1.4.1
Server API version: 1.16
Go version (server): go1.3.3
Git commit (server): 5bc2ff8

$ uname -a
Linux medi-it-sote 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

This happens occasionally, any ideas?

[unclejack]

@deiga Please provide full output of docker info, docker version and uname -a. There's no way to help without this information. Please provide these bits of information when reporting an issue or commenting on an issue reported by someone else to say you're also running into the same problem.

[deiga]

@unclejack Yes, of course. I updated the original question with the information you asked for

[khoamisfit]

#10528 . Same problem.

[ianwalter]

+1

[bitcraf0101]

+1

[vankhoa011]

It is fixed in docker 1.5 version.

[jessfraz]

is anyone else in this thread using 1.5

[bitcraf0101]

Thanks for the feedback. We will update to 1.5.

[jessfraz]

so I am going to close this, BUT if you see it still on 1.5 ping me to reopen

[pikeas]

@jfrazelle I have what appears to be a zombie container - it can't be stopped, killed, rmed, or rm -fed.

Mar 13 08:32:35 localhost dockerd[539]: time="2015-03-13T08:32:35Z" level="info" msg="Container 3f3229afeff0 failed to exit within 10 seconds of kill - trying direct SIGKILL"
(container remains up)

core@localhost ~ $ docker info
Containers: 4
Images: 141
Storage Driver: overlay
 Backing Filesystem: extfs
Execution Driver: native-0.2
Kernel Version: 3.19.0
Operating System: CoreOS 612.1.0
CPUs: 1
Total Memory: 998 MiB

core@localhost ~ $ docker version
Client version: 1.5.0
Client API version: 1.17
Go version (client): go1.3.3
Git commit (client): a8a31ef-dirty
OS/Arch (client): linux/amd64
Server version: 1.5.0
Server API version: 1.17
Go version (server): go1.3.3
Git commit (server): a8a31ef-dirty

core@localhost ~ $ uname -a
Linux localhost 3.19.0 #2 SMP Fri Mar 6 00:23:51 UTC 2015 x86_64 Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz GenuineIntel GNU/Linux

[pikeas]

Found a couple of clues.

After rebooting the VM, the container can be removed.

The issue is reproducible on my system. I can share my Dockerfile if needed, but here's the gist: OS X host, CoreOS VM managed by Vagrant as docker host, base image is dockerfile/ubuntu:latest. I'm mounting a volume into the container (using Vagrant's NFS mount), and then doing an npm install. The container freezes up part way through the install process - I can't ctrl+c the install, can't stop the container, or even docker exec a new shell into it.

[phanimahesh]

Issue still exists on v1.7

[calavera]

There is more info about this in #12738.

[iyn]

I'm also experiencing this problem.
Host: Arch Linux (amd64), using Vagrant with CoreOS & NFS

Any plans to solve this? Are there any known solutions?

[mhf-ir]

Same problem debian jessie x64

# docker --version 
Docker version 1.6.2, build 7c8fca2

docker ps -a
CONTAINER ID        IMAGE                                                                     COMMAND             CREATED             STATUS                      PORTS               NAMES
f1bea984deae        8eb20e13c4d8b82408c60eccea35bea0d5e99a224f0d6065b33b819c7e777a26:latest   "-exec /bin/bash"   12 minutes ago 

# docker stop f1bea984deae
f1bea984deae

# docker rmi 8eb20e13c4d8b82408c60eccea35bea0d5e99a224f0d6065b33b819c7e777a26 
Error response from daemon: Conflict, cannot delete 8eb20e13c4d8 because the container f1bea984deae is using it, use -f to force
FATA[0000] Error: failed to remove one or more images

[kiron783]

Removal In Progress for more than an hour :(

[neverfox]

Same (running containers off the official cassandra image):

Containers: 3
Images: 13
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /mnt/sda1/var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 19
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.1.13-boot2docker
Operating System: Boot2Docker 1.9.1 (TCL 6.4.1); master : cef800b - Fri Nov 20 19:33:59 UTC 2015
CPUs: 1
Total Memory: 996.2 MiB
Name: default
ID: 323I:I66I:JYQC:XBC6:K5OO:5VH2:EQ23:3YCL:WWOX:IUJ4:ECBY:6RUX
Debug mode (server): true
 File Descriptors: 39
 Goroutines: 103
 System Time: 2015-11-21T06:35:22.202794522Z
 EventsListeners: 1
 Init SHA1:
 Init Path: /usr/local/bin/docker
 Docker Root Dir: /mnt/sda1/var/lib/docker
Labels:
 provider=virtualbox

Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.5.1
 Git commit:   a34a1d5
 Built:        Sat Nov 21 00:49:19 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64

Darwin Soma.nc.rr.com 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19 15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

[jinyk]

I had similar problem trying to run then exit out or or kill sequenceiq/spark:1.5.1. Once I increased the memory of the VM from 2GB to 3GB everything worked fine.

[daddykotex]

@neverfox exactly the same problem here, with the same image +1

~ docker version
Client:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.5.1
 Git commit:   a34a1d5
 Built:        Sat Nov 21 00:49:19 UTC 2015
 OS/Arch:      darwin/amd64

Server:
 Version:      1.9.1
 API version:  1.21
 Go version:   go1.4.3
 Git commit:   a34a1d5
 Built:        Fri Nov 20 17:56:04 UTC 2015
 OS/Arch:      linux/amd64


~ docker-machine inspect default
{
    "ConfigVersion": 3,
    "Driver": {
        "Driver": {
            "VBoxManager": {},
            "IPAddress": "192.168.99.100",
            "MachineName": "default",
            "SSHUser": "docker",
            "SSHPort": 61012,
            "SSHKeyPath": "/Users/myuser/.docker/machine/machines/default/id_rsa",
            "StorePath": "/Users/myuser/.docker/machine",
            "SwarmMaster": false,
            "SwarmHost": "tcp://0.0.0.0:3376",
            "SwarmDiscovery": "",
            "CPU": 1,
            "Memory": 4096,
            "DiskSize": 20000,
            "Boot2DockerURL": "",
            "Boot2DockerImportVM": "",
            "HostOnlyCIDR": "192.168.99.1/24",
            "HostOnlyNicType": "82540EM",
            "HostOnlyPromiscMode": "deny",
            "NoShare": false
        },
        "Locker": {}
    },
    "DriverName": "virtualbox",
    "HostOptions": {
        "Driver": "",
        "Memory": 0,
        "Disk": 0,
        "EngineOptions": {
            "ArbitraryFlags": [],
            "Dns": null,
            "GraphDir": "",
            "Env": [],
            "Ipv6": false,
            "InsecureRegistry": [],
            "Labels": [],
            "LogLevel": "",
            "StorageDriver": "",
            "SelinuxEnabled": false,
            "TlsVerify": true,
            "RegistryMirror": [],
            "InstallURL": "https://get.docker.com"
        },
        "SwarmOptions": {
            "IsSwarm": false,
            "Address": "",
            "Discovery": "",
            "Master": false,
            "Host": "tcp://0.0.0.0:3376",
            "Image": "swarm:latest",
            "Strategy": "spread",
            "Heartbeat": 0,
            "Overcommit": 0,
            "ArbitraryFlags": [],
            "Env": null
        },
        "AuthOptions": {
            "CertDir": "/Users/myuser/.docker/machine/certs",
            "CaCertPath": "/Users/myuser/.docker/machine/certs/ca.pem",
            "CaPrivateKeyPath": "/Users/myuser/.docker/machine/certs/ca-key.pem",
            "CaCertRemotePath": "",
            "ServerCertPath": "/Users/myuser/.docker/machine/machines/default/server.pem",
            "ServerKeyPath": "/Users/myuser/.docker/machine/machines/default/server-key.pem",
            "ClientKeyPath": "/Users/myuser/.docker/machine/certs/key.pem",
            "ServerCertRemotePath": "",
            "ServerKeyRemotePath": "",
            "ClientCertPath": "/Users/myuser/.docker/machine/certs/cert.pem",
            "StorePath": "/Users/myuser/.docker/machine/machines/default"
        }
    },
    "Name": "default",
    "RawDriver": "eyJWQm94TWFuYWdlciI6e30sIklQQWRkcmVzcyI6IjE5Mi4xNjguOTkuMTAwIiwiTWFjaGluZU5hbWUiOiJkZWZhdWx0IiwiU1NIVXNlciI6ImRvY2tlciIsIlNTSFBvcnQiOjYxMDEyLCJTU0hLZXlQYXRoIjoiL1VzZXJzL2RhdmlkZnJhbmNvZXVyLy5kb2NrZXIvbWFjaGluZS9tYWNoaW5lcy9kZWZhdWx0L2lkX3JzYSIsIlN0b3JlUGF0aCI6Ii9Vc2Vycy9kYXZpZGZyYW5jb2V1ci8uZG9ja2VyL21hY2hpbmUiLCJTd2FybU1hc3RlciI6ZmFsc2UsIlN3YXJtSG9zdCI6InRjcDovLzAuMC4wLjA6MzM3NiIsIlN3YXJtRGlzY292ZXJ5IjoiIiwiQ1BVIjoxLCJNZW1vcnkiOjQwOTYsIkRpc2tTaXplIjoyMDAwMCwiQm9vdDJEb2NrZXJVUkwiOiIiLCJCb290MkRvY2tlckltcG9ydFZNIjoiIiwiSG9zdE9ubHlDSURSIjoiMTkyLjE2OC45OS4xLzI0IiwiSG9zdE9ubHlOaWNUeXBlIjoiODI1NDBFTSIsIkhvc3RPbmx5UHJvbWlzY01vZGUiOiJkZW55IiwiTm9TaGFyZSI6ZmFsc2V9"
}
➜  ~  docker inspect 74
[
{
    "Id": "7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04",
    "Created": "2015-11-27T13:23:11.515987776Z",
    "Path": "/docker-entrypoint.sh",
    "Args": [
        "cassandra",
        "-f"
    ],
    "State": {
        "Status": "running",
        "Running": true,
        "Paused": false,
        "Restarting": false,
        "OOMKilled": false,
        "Dead": false,
        "Pid": 1263,
        "ExitCode": 0,
        "Error": "",
        "StartedAt": "2015-11-27T13:23:11.612899257Z",
        "FinishedAt": "0001-01-01T00:00:00Z"
    },
    "Image": "338a92b912e4d5a84c4f399a9475a1476f8226eff85c2592c8e80ba58b13d225",
    "ResolvConfPath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/resolv.conf",
    "HostnamePath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/hostname",
    "HostsPath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/hosts",
    "LogPath": "/mnt/sda1/var/lib/docker/containers/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04/7471b734d7e7e47270511453a04d903c974cba77a2a0d259255355a653f95e04-json.log",
    "Name": "/pensive_kalam",
    "RestartCount": 0,
    "Driver": "aufs",
    "ExecDriver": "native-0.2",
    "MountLabel": "",
    "ProcessLabel": "",
    "AppArmorProfile": "",
    "ExecIDs": null,
    "HostConfig": {
        "Binds": null,
        "ContainerIDFile": "",
        "LxcConf": [],
        "Memory": 0,
        "MemoryReservation": 0,
        "MemorySwap": 0,
        "KernelMemory": 0,
        "CpuShares": 0,
        "CpuPeriod": 0,
        "CpusetCpus": "",
        "CpusetMems": "",
        "CpuQuota": 0,
        "BlkioWeight": 0,
        "OomKillDisable": false,
        "MemorySwappiness": -1,
        "Privileged": false,
        "PortBindings": {},
        "Links": null,
        "PublishAllPorts": false,
        "Dns": [],
        "DnsOptions": [],
        "DnsSearch": [],
        "ExtraHosts": null,
        "VolumesFrom": null,
        "Devices": [],
        "NetworkMode": "default",
        "IpcMode": "",
        "PidMode": "",
        "UTSMode": "",
        "CapAdd": null,
        "CapDrop": null,
        "GroupAdd": null,
        "RestartPolicy": {
            "Name": "no",
            "MaximumRetryCount": 0
        },
        "SecurityOpt": null,
        "ReadonlyRootfs": false,
        "Ulimits": null,
        "LogConfig": {
            "Type": "json-file",
            "Config": {}
        },
        "CgroupParent": "",
        "ConsoleSize": [
            0,
            0
        ],
        "VolumeDriver": ""
    },
    "GraphDriver": {
        "Name": "aufs",
        "Data": null
    },
    "Mounts": [
        {
            "Name": "2249b03f9a598e5ac3f306983877292baa299c4499c9db77eb9bfcb88fd2f541",
            "Source": "/mnt/sda1/var/lib/docker/volumes/2249b03f9a598e5ac3f306983877292baa299c4499c9db77eb9bfcb88fd2f541/_data",
            "Destination": "/var/lib/cassandra",
            "Driver": "local",
            "Mode": "",
            "RW": true
        }
    ],
    "Config": {
        "Hostname": "7471b734d7e7",
        "Domainname": "",
        "User": "",
        "AttachStdin": false,
        "AttachStdout": true,
        "AttachStderr": true,
        "ExposedPorts": {
            "7000/tcp": {},
            "7001/tcp": {},
            "7199/tcp": {},
            "9042/tcp": {},
            "9160/tcp": {}
        },
        "Tty": false,
        "OpenStdin": false,
        "StdinOnce": false,
        "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
            "CASSANDRA_VERSION=2.1.11",
            "CASSANDRA_CONFIG=/etc/cassandra"
        ],
        "Cmd": [
            "cassandra",
            "-f"
        ],
        "Image": "cassandra:2.1.11",
        "Volumes": {
            "/var/lib/cassandra": {}
        },
        "WorkingDir": "",
        "Entrypoint": [
            "/docker-entrypoint.sh"
        ],
        "OnBuild": null,
        "Labels": {},
        "StopSignal": "SIGTERM"
    },
    "NetworkSettings": {
        "Bridge": "",
        "SandboxID": "e2f074e4b10e67cd7ac22d6e73d50304fc3f0a68d67c7fee6d7f8d647c9eb9b1",
        "HairpinMode": false,
        "LinkLocalIPv6Address": "",
        "LinkLocalIPv6PrefixLen": 0,
        "Ports": {
            "7000/tcp": null,
            "7001/tcp": null,
            "7199/tcp": null,
            "9042/tcp": null,
            "9160/tcp": null
        },
        "SandboxKey": "/var/run/docker/netns/e2f074e4b10e",
        "SecondaryIPAddresses": null,
        "SecondaryIPv6Addresses": null,
        "EndpointID": "63596aa5ec20516d477921fec4197d086b4dd4f1ad25014b5ddf027b82891966",
        "Gateway": "172.17.0.1",
        "GlobalIPv6Address": "",
        "GlobalIPv6PrefixLen": 0,
        "IPAddress": "172.17.0.2",
        "IPPrefixLen": 16,
        "IPv6Gateway": "",
        "MacAddress": "02:42:ac:11:00:02",
        "Networks": {
            "bridge": {
                "EndpointID": "63596aa5ec20516d477921fec4197d086b4dd4f1ad25014b5ddf027b82891966",
                "Gateway": "172.17.0.1",
                "IPAddress": "172.17.0.2",
                "IPPrefixLen": 16,
                "IPv6Gateway": "",
                "GlobalIPv6Address": "",
                "GlobalIPv6PrefixLen": 0,
                "MacAddress": "02:42:ac:11:00:02"
            }
        }
    }
}
]

I simply ran docker run -it cassandra:2.1.11 and your terminal will be stuck, no way to stop the container. You have to stop the whole VM.

[cjbottaro]

Same issue with our own Cassandra 2.1.11 image (based on ubuntu:14.04). It seems that something is causing it to shutdown (definitely not us) and then hanging in the process of that. Here's the end of docker logs ...:

INFO  21:42:19 Completed flushing /usr/local/cassandra/bin/../data/data/system/size_estimates-618f817b005f3678b8a453f3930b8e86/system-size_estimates-tmp-ka-112-Data.db (311.442KiB) for commitlog position ReplayPosition(segmentId=1449856646021, position=24189495)
INFO  22:21:09 Stop listening to thrift clients
INFO  22:21:09 Stop listening for CQL clients
INFO  22:21:09 Announcing shutdown
INFO  22:21:09 Node localhost/127.0.0.1 state jump to normal

[jayfk]

Same issue with the official icinga/icinga2 image. The only way to stop the container was to reboot the machine.

[elhu]

We had the same issue. It seemed to have occurred when the server's kernel was upgraded to 3.13.0-73.116.

We reverted the kernel to 3.13.0-71.114, which seems to have fixed the problem for us.

[mulyoved]

Experience the problem with Docker 1.9.1 and Linux 3.13.0-74

Other identical load with older Linux (3.13.0-24-generic) does not seem to have this problem

[ptepper]

I'm seeing this same issue with 3.13.0-74 under Ubuntu 14.04.3 LTS. I tried upgrading to newer kernels under Ubuntu vivid (3.19.xx) and wily (4.2.0-22) with the same results.

Containers: 12
Images: 175
Server Version: 1.9.1
Storage Driver: aufs
 Root Dir: /var/lib/docker/aufs
 Backing Filesystem: extfs
 Dirs: 199
 Dirperm1 Supported: true
Execution Driver: native-0.2
Logging Driver: json-file
Kernel Version: 4.2.0-22-generic
Operating System: Ubuntu 14.04.3 LTS
CPUs: 4
Total Memory: 29.96 GiB

Downgrading to the 3.13.xx seems to fix the problem.

[cjbottaro]

Is there a new issue for this since this one is closed and no one from Docker, Inc seems to be following it?

[petetnt]

Having this issue every once in a while with Docker For Mac beta, Docker version 1.12.0-rc4, build e4a0dbc, experimental.

Zombie containers refuse to take in any commands (stop, rm...), but restarting Docker For Mac and retrying helps.

[ShevYan]

I think we should make sure whether the issue is 'hang' or 'fail'.
If it's a hang issue:
Identify the hang position (most likely is hang in daemon), so 'kill -SIGUSR1 <daemon_pid>'and then pasting the goroutines' stacktrace will be helpful. Sometimes it may stuck in kernel, so should get all the kernel thread info by 'echo t > /proc/sysrq-triger'.
If it's a failure issue:
I also met the same issue. The PID is stored in memory, but the process already disappeared.

[gokhansengun]

I am experiencing this issue once out of two times under 4.2.0-27-generic #32~14.04.1-Ubuntu. It could never be reproduced under Docker for Mac which I find quite interesting, may point to Ubuntu. Both builds are like below.

Version:      1.12.0
API version:  1.24
Go version:   go1.6.3
Git commit:   8eab29e

[Ehekatl]

Hi guys, just figure out what's happening on my side, in my case, I have a mounted volume delete before restarting the container, but there is no error for the missing volume, and after reboot instance the container will successfully boot up (with --restart=always), it will create the missing volume directory it self, that cause me can't find what really cause this problem.

[icecrime]

Cc @tonistiigi: PTAL.

[tonistiigi]

I think we should close this. Like @thaJeztah said, this is a collection of unrelated problems. There are people commenting with their docker info but I have no idea which problem they are even referring to as the error message from original report was gone already in v1.7.0. #22423 matches most of the descriptions in here and is fixed with v1.12. If you have trouble removing a container, please start a new issue, include information about the specifics of your container and daemon logs. If it is a hang then send SIGUSR1 signal to docker daemon and include it in the issue report as suggested in #10589 (comment) .

[icecrime]

I'm closing this, blame him ☝️

On a more serious note, please let us know if you believe this issue needs reopening.

[gokhansengun]

Guys, you are consolidating issues into one by telling they are the same issue which is OK. Then you are closing the issue complaining that there are multiple issues in one bug report.

People are looking for workarounds when they get no love in here. Closing issues without addressing the problem does not make any sense.

[tonistiigi]

@gokhansengun If you have a problem in v1.12 then please start a new issue with full report data. Given that this was reported in v1.4 and you have something similar in v1.12 it is very unlikely that these problems have the same cause. As I said in my comment it is impossible that you got the same exact error message as it has been removed a year before v1.12 was released. At least some of the people here got a fix with #22423 or even earlier. If we have more issues left we need new report data about them so they can be solved.

[ghost]

Problem exists in:
Docker version 1.10.3, build 3cd164c

coreOS host

[gokhansengun]

For what it is worth, my problem was related with the OS, namely Ubuntu 14.04. Changed it to Centos 7 and 50% repro on Ubuntu Box is now 0% on Centos 7. Both are running Docker version 1.12

[tonistiigi]

@gokhansengun What is your 50% repro in ubuntu? If you have a reproducible testcase please open an issue for it so it can be fixed.

[gokhansengun]

@tonistiigi a JMeter image based on official Java:7 image causes 99% cpu while running JMeter test scripts. I got rid of Ubuntu 14.04 alltogether but let me see what I can do. Will let the issue number given here.

[gokhansengun]

I am unfortunately unable to reproduce it with using boxcutter/ubuntu1404 image with Vagrant. The original repro VM has already gone as said and I seem to have no way to reproduce now, sorry.

[drlukeangel]

this is closed but i am running into a issue with the same outcome as well as some other people on these tickets.
docker-archive/classicswarm#2304
#26017
all using swarm mode docker 1.2

[dmabuada]

I'm also having this issue with Docker for Mac @petetnt. Running Docker version 1.12.1 though.

[cswarth]

I've seen this when running the dockcross/linux-arm64 container (based on debian:jessie) under 1.13.0-rc3 on a Mac. It is not reliable, but sometime interrupting a build with ^C will hang the process. Attempting the restart docker will not work and the docker process is consuming 100% cpu. The only way to fix it that I know of is to reboot the machine.

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.12.1
BuildVersion:   16B2555

$ docker version
Client:
 Version:      1.13.0-rc3
 API version:  1.25
 Go version:   go1.7.3
 Git commit:   4d92237
 Built:        Tue Dec  6 01:15:44 2016
 OS/Arch:      darwin/amd64

Server:
 Version:      1.13.0-rc3
 API version:  1.25 (minimum version 1.12)
 Go version:   go1.7.3
 Git commit:   4d92237
 Built:        Tue Dec  6 01:15:44 2016
 OS/Arch:      linux/amd64
 Experimental: true

[miry]

I have same or similar issue for docker 1.12.3 and 1.12.5. A process was killed. but docker still shows it in the list and docker stop container_id is stuck. Mostly images base on java. One of them official Elasticsearch images v2. Also have storage type overlay.

[faizalzakaria]

Having the same issue with Docker version 1.13.0, build 49bf474, ubuntu 14.04. After the container been running for a long period of time.

[thinkhard-j-park]

Hi,

I have encountered same problem. I had run mongodb, kafka images upon ubuntu 16.04
Please see belows,

docker stop broker02.1.1rf7j2a6njxycwjbc6hc069k2
Error response from daemon: Cannot stop container broker02.1.1rf7j2a6njxycwjbc6hc069k2: Cannot kill container e1da77e2e13b681312d8bd6bab019c607cc16b88a0696826b2593dc093d34047: rpc error: code = 14 desc = grpc: the connection is unavailable

docker version
Client:
Version: 1.13.0
API version: 1.25
Go version: go1.7.3
Git commit: 49bf474
Built: Tue Jan 17 09:58:26 2017
OS/Arch: linux/amd64

Server:
Version: 1.13.0
API version: 1.25 (minimum version 1.12)
Go version: go1.7.3
Git commit: 49bf474
Built: Tue Jan 17 09:58:26 2017
OS/Arch: linux/amd64
Experimental: false

Containers: 35
Running: 6
Paused: 0
Stopped: 29
Images: 13
Server Version: 1.13.0
Storage Driver: aufs
Root Dir: /var/lib/docker/aufs
Backing Filesystem: extfs
Dirs: 151
Dirperm1 Supported: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Plugins:
Volume: local
Network: bridge host macvlan null overlay
Swarm: active
NodeID: mvimcgosd3ajnul07i7s23puw
Is Manager: false
Node Address: 192.168.0.29
Manager Addresses:
192.168.0.27:2377
192.168.0.32:2377
192.168.0.33:2377
Runtimes: runc
Default Runtime: runc
Init Binary: docker-init
containerd version: N/A (expected: 03e5862ec0d8d3b3f750e19fca3ee367e13c090e)
runc version: 2f7393a47307a16f8cee44a37b262e8b81021e3e
init version: 949e6fa
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 4.4.0-62-generic
Operating System: Ubuntu 16.04.1 LTS
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 7.797 GiB
Name: worker01
ID: 3BUL:LI3A:ZTCA:RKJE:VGDN:FNVG:5ROB:ZPFV:UYIN:W5AU:HMLK:VOA2
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
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

[ValRu]

Hey,

Having the same running following

docker kill $(docker ps -qa)

Error response from daemon: Cannot kill container 0b9617dff904: Container 0b9617dff904520ccb903a861281c44a9a2ce7aa3bc3f024c779028fdb073b36 is not running

The docker version is

Client:
Version: 1.12.2-cs2-ws-beta
API version: 1.25
Go version: go1.7.1
Git commit: 050b611
Built: Tue Oct 11 02:35:40 2016
OS/Arch: windows/amd64

Server:
Version: 1.12.2-cs2-ws-beta
API version: 1.25
Go version: go1.7.1
Git commit: 050b611
Built: Tue Oct 11 02:35:40 2016
OS/Arch: windows/amd64

OS:

Caption : Microsoft Windows Server 2016 Datacenter
OSType : 18
Version : 10.0.14393

[thaJeztah]

@ValentinRueda looks not related to this issue; you specify -qa, which includes stopped containers; so the error message is correct, because a stopped container cannot be killed

[thaJeztah]

I am locking the conversation on this issue, per #10589 (comment)

I think we should close this. Like @thaJeztah said, this is a collection of unrelated problems. There are people commenting with their docker info but I have no idea which problem they are even referring to as the error message from original report was gone already in v1.7.0. #22423 matches most of the descriptions in here and is fixed with v1.12. If you have trouble removing a container, please start a new issue, include information about the specifics of your container and daemon logs. If it is a hang then send SIGUSR1 signal to docker daemon and include it in the issue report as suggested in #10589 (comment) .