Description
Consider the following situation: you are booting up a database container and then a web container which links to the database container. The database container may take a little time to start up, but you don't want to start the web container until the database has started.
A similar situation is where you are starting up a web server and want to wait until it has started before adding it to the load balancer.
Current solutions typically involve an entrypoint script that waits for the port to be open (see docker/compose#374 or aanand/docker-wait, or even just a fixed /bin/sleep command.
I propose that a container should not be considered started or be able to be linked to until the exposed TCP ports are ready to accept connections. The docker run -d or docker start commands should also not return until they are ready. This will allow you to safely do things like:
$ docker run -d --name db postgres
$ docker run -d -l db:db mywebapp
I am not fully familiar with the internals of container state, so I'm not sure how this should be implemented. I expect it'll be something like a Ready attribute on a container's state, perhaps with a modification to the /container/(id)/wait endpoint that will wait for a container to be ready.
Backwards compatibility
Existing containers may not open exposed ports. Perhaps there could be a timeout, or it could be an opt-in feature in a next version, switching to default behaviour in a version after that.
Future
This could be expanded into some kind of health check system. E.g. don't consider a container started and ready to be linked to until it is responding to HTTP requests with code 200.