Daemon restart not starting containers with shared network in the correct order (--network=container:...)

Author: stevenboydCreated Mar 25, 2015Updated Sep 28, 2026

Labelsarea/runtimekind/featurearea/networkingversion/1.3

If you have two containers both with a restart policy of always and they share a network stack, the docker daemon may not start them in the correct order.

For example, if you have two containers started like so

bash

docker run -d --name a --restart always some_image
docker run -d --name b --restart always --net=container:a some_other_image

Then you restart the docker daemon, it may try and restart container b before container a, causing container b to fail to start up and this message to show up in the daemon logs

[debug] daemon.go:384 Failed to start container id_of_b: cannot join network of a non running container: a

I would expect docker to boot up container a before container b, much like it boots up linked containers in the correct order.

bash

docker version
Client version: 1.3.2
Client API version: 1.15
Go version (client): go1.3.3
Git commit (client): 39fa2fa/1.3.2
OS/Arch (client): linux/amd64
Server version: 1.3.2
Server API version: 1.15
Go version (server): go1.3.3
Git commit (server): 39fa2fa/1.3.2

bash

docker info
Containers: 3
Images: 233
Storage Driver: devicemapper
 Pool Name: docker-253:2-131678-pool
 Pool Blocksize: 65.54 kB
 Data file: /var/lib/docker/devicemapper/devicemapper/data
 Metadata file: /var/lib/docker/devicemapper/devicemapper/metadata
 Data Space Used: 11.31 GB
 Data Space Total: 107.4 GB
 Metadata Space Used: 17.21 MB
 Metadata Space Total: 2.147 GB
 Library Version: 1.02.89-RHEL6 (2014-09-01)
Execution Driver: native-0.2
Kernel Version: 2.6.32-504.3.3.el6.x86_64
Operating System: <unknown>
Debug mode (server): true
Debug mode (client): false
Fds: 16
Goroutines: 13
EventsListeners: 0
Init SHA1: da6572a9f895dbbc52c7a03d3d391e45e56dc021
Init Path: /usr/libexec/docker/dockerinit
Username: appfoliodocker
Registry: [https://index.docker.io/v1/]

Environment details (AWS, VirtualBox, physical, etc.): CentOS 6.6 box

How reproducible: It seems that a given configuration of containers will reliably fail. However it seems adding or removing other containers can change the load order and may produce different results.

Source: moby/moby

View original on GitHub View discussion on GitHub