docker run can't rely on the Events API. #100
Description
Moved from moby/moby#32242
Description
Since Docker 1.13, the implementation of docker run ... changed to use the Events API over ContainerWait to wait for the container to exit. This was done to facilitate the move of handling autoRemove on the daemon rather than the CLI - the problem with the Wait API being that it only waited for the container to exit, and not for the container to be removed which would cause race conditions if, for example, a successive CLI command tried to create a container with the same name and it had not yet been cleaned up by the daemon.
While there is no problem with this Events API approach when connecting directly to the docker daemon
which is running the container, I have seen several issue with it when the "daemon" is actually a Docker Swarm cluster (classic swarm, not swarmkit). One major problem is that swarm does not support event filtering at all, and so it ignores the container filter and ends up streaming back all cluster events. This means that your CLI may receive a "die" event for another container, causing your CLI to exit pre-maturely. Even if filtering were added to the swarm manager, there is yet another issue where its aggregated event stream is not reliable - it may temporarily lose the event stream from the engine which is running the target container but will not disconnect the client because the aggregate stream as a whole is still working. If the container exits during this short disconnection window, the events will never be sent to the CLI and it will hang forever. There is no way to guarantee that the event will be sent back to the client.
