Docker daemon threads can become affixed to a container's network namespace, causing network errors later when the container is stopped (default network)

[samuelkarp]

This is very similar to #1113, which concerns the embedded DNS server in non-default networks. However, running our repro script based on the repro provided in #1113, we're able to observe the same effect (daemon threads in a container's network namespace) while using a default network.

We've tested this in a few different configurations, and have the following results:

• Docker 1.11.0 as released, Go 1.5.3, GOMAXPROCS unset: 73 failures/2000 runs, 3.6% failure rate
• Docker 1.11.0 + patch from Move the iptables setup for embedded DNS into a reexec process #1115, Go 1.5.3, GOMAXPROCS unset: 76 failures/2000 runs, 3.8% failure rate
• Docker 1.11.0 + patch from Move the iptables setup for embedded DNS into a reexec process #1115, Go 1.5.3, GOMAXPROCS=1: 482 failures/1900 runs, 25.3% failure rate
• Docker 1.11.0 + patch from Move the iptables setup for embedded DNS into a reexec process #1115, Go 1.4.2, GOMAXPROCS unset: 463 failures/2000 runs, 23.1% failure rate
• Docker 1.11.0 as released, Go 1.4.2, GOMAXPROCS unset: 407 failures/2000 runs, 20.3% failure rate
• Docker 1.9.1, Go 1.4.2, GOMAXPROCS unset: 21 failures/1900 runs, 1.1% failure rate

These tests were all run on Amazon EC2 instances running the Amazon Linux AMI on a mix of different instance types.

From these results, it looks like it has been a problem for a while, but got worse more recently.

[euank]

More recent docker versions (post the containerd/runc split) have changed significantly. Is this bug still accurate, or was it fixed somewhere along the way and not closed?