Port number 49153(BeginPortRange) would be returned twice, causing dupli...
Upstream-commit: 0e6242122d9780709c057fc32e9970529c2e09fb
Component: engine
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: ee17b93df9ef2150d0ef25e077f1f87637a54508
Component: engine
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 6589044b5b84f82a71a756708b4a77b0bc49db42
Component: engine
Docker-DCO-1.1-Signed-off-by: Phil Estes <estesp@linux.vnet.ibm.com> (github: estesp)
Upstream-commit: 9b430f4ec1083d2e73abe4269a85c8cdd91a5ade
Component: engine
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>
Upstream-commit: 9451cf39eff037eccb04319c1e601d08495cab3c
Component: engine
MemInfo provides a simple API to get memory information from the
system.
Signed-off-by: Andrea Luzzardi <aluzzardi@gmail.com>
Upstream-commit: e0c9d7b654221a0d4e5a310b0f9a0adb9ef69aa0
Component: engine
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>
Upstream-commit: ba5370c116e3879c88736d3456586ec5703f581b
Component: engine
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>
Upstream-commit: 5df2c878a1b2baeb22538bb66be631b8da33236a
Component: engine
The CLI commands had long dashes that won't work on most terminals when copy pasting.
Signed-off-by: wilsaj <wilson.andrew.j+github@gmail.com>
Upstream-commit: 36dae27fa26fe58efaf68296169cd2c6ba6dfcfe
Component: engine
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)
Upstream-commit: 6ed610fb8014d500e001bb0677f0e1af0dc9312d
Component: engine
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>
Upstream-commit: ef98fe0763024abd90bd5a573fec816895ee92e4
Component: engine
