If we first request port 49153 (BeginPortRange) explicitly, and later some time request the next free port (of same ip/proto) by calling RequestPort() with port number 0, we will again get 49153 returned, even if it's currently in use. Because findPort() blindly retured BeginPortRange the first run, without checking if it has already been taken.
Signed-off-by: shuai-z <zs.broccoli@gmail.com>
when a container failed to start, saves the error message into State.Error so
that it can be retrieved when calling `docker inspect` instead of having to
look at the log
Docker-DCO-1.1-Signed-off-by: Daniel, Dao Quang Minh <dqminh89@gmail.com> (github: dqminh)
Never close attached stream before both stdout and stderr have written
all their buffered contents. Remove stdinCloser because it is not needed
any more as the stream is closed anyway after attach has finished.
Fixes#3631
Signed-off-by: Andy Goldstein <agoldste@redhat.com>
Do not run containers in the background in the integration tests if you
depend on the run completing. It is better especially if you just want
to ensure that the run has completed with a `true` to just run in
foreground and use a known name for the container to query it after it
has stopped.
The failures can be reproduced on most machines by giving your dind
container one core and a cpushare.
docker run -c 200 --cpuset 0 -ti --rm --privileged -e
DOCKER_GRAPHDRIVER=vfs docker hack/make.sh binary test-integration-cli
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
As of 1.3 `docker ps` no longer shows links between containers.
This updates the documentation to reflect that change.
sudo docker docker inspect -f "{{ .HostConfig.Links }}" web
Signed-off-by: Philipp Weissensteiner <mail@philippweissensteiner.com>
graphdriver is not always specified when the log printed, because
it's provided in another thread. This patch will fix this.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
So far, it looks like the declarations are not used, and so its safer not to
confuse people into thinking they do something.
Docker-DCO-1.1-Signed-off-by: Sven Dowideit <SvenDowideit@docker.com> (github: SvenDowideit)
Fixes#1992
Right now when you `docker cp` a path which is in a volume, the cp
itself works, however you end up getting files that are in the
container's fs rather than the files in the volume (which is not in the
container's fs).
This makes it so when you `docker cp` a path that is in a volume it
follows the volume to the real path on the host.
archive.go has been modified so that when you do `docker cp mydata:/foo
.`, and /foo is the volume, the outputed folder is called "foo" instead
of the volume ID (because we are telling it to tar up
`/var/lib/docker/vfs/dir/<some id>` and not "foo", but the user would be
expecting "foo", not the ID
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Andrea Luzzardi