moby: `docker start` fails with mkdir-file-exists error

Output of docker version:

$ docker version
Client:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:23:39 2016
 OS/Arch:      linux/amd64

Server:
 Version:      1.11.2
 API version:  1.23
 Go version:   go1.5.4
 Git commit:   b9f10c9
 Built:        Wed Jun  1 21:23:39 2016
 OS/Arch:      linux/amd64

Output of docker info:

$ sudo docker info
Containers: 6
 Running: 6
 Paused: 0
 Stopped: 0
Images: 256
Server Version: 1.11.2
Storage Driver: btrfs
 Build Version: Btrfs v3.17
 Library Version: 101
Logging Driver: journald
Cgroup Driver: cgroupfs
Plugins: 
 Volume: local
 Network: bridge null host
Kernel Version: 3.16.0-4-amd64
Operating System: Debian GNU/Linux 8 (jessie)
OSType: linux
Architecture: x86_64
CPUs: 8
Total Memory: 62.88 GiB
Name: myhost
ID: NJB5:TOIZ:DXP7:USNB:HF4N:7AO3:DHP6:RZZ4:5WK2:345Z:FFZN:5NLS
Docker Root Dir: /var/lib/docker
Debug mode (client): false
Debug mode (server): false
Registry: https://index.docker.io/v1/
WARNING: No kernel memory limit support
WARNING: No cpu cfs quota support
WARNING: No cpu cfs period support

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

Debian 8.4 with systemd

Steps to reproduce the issue:

Restart Docker daemon (sudo systemctl restart docker.service) (in my case it was killed by itself because it was unresponsive (systemd[1]: docker.service stop-sigterm timed out. Killing.) – different error/problem)

Describe the results you received:

All containers couldn’t be started anymore with the error message below.

$ sudo docker start memcached
mkdir /run/containerd/b0588906e76e252481c879903d88663708b1a27c33d5082a1ee06656d01eb43a: file exists

After a restart of the system the container could be started again.

Describe the results you expected:

The container should start after a problem with the Docker daemon without the need to reboot the server.

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

This is a production server, so it’s not possible to try to reproduce this, that means, just killing the Docker deamon for fun.

This looks similar to #21702, which has been closed though, is supposedly fixed although other people comment that they still experience this.

About this issue

Original URL
State: closed
Created 8 years ago
Comments: 26 (14 by maintainers)

Most upvoted comments

In addition to what @TooDizzy said, I think it happened to me because I changed my Windows Directory password and Docker may have been using the old credentials and thereby failing. Once I clicked on “Apply”, Docker asked me for the new credentials, and it started working properly after I supplied the new ones.

And the following is the place I am talking about:

tarikguney on Nov 28, 2016

Encountered the same thing today on Windows running docker version 1.12.3.

The problem went away after I went in to the “Shared Drives” section of the Docker windows settings window and pressed the “Apply” button.

TooDizzy on Nov 24, 2016

@thaJeztah, @tonistiigi, thank you for your responses and hints. I did not try the workarounds, as I was not sure, if that’s safe. But I guess deleting stuff under /run is safe, if a container is stopped.

But as it’s a workaround, I am more interested in what the theories are, that the files under /run are not cleaned up by Docker itself. Is that expected if the Docker daemon is killed/stops working?

paulmenzel on Aug 1, 2016