This fix tries to address the issue raised in 30178 where
service healthcheck is `{}` in remote API will result in
dns resolve failue.
The reason was that when service healthcheck is `{}`,
service binding was not done.
This fix fixes the issue.
An integration test has been added.
This fix fixes 30178.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
(cherry picked from commit 8feb5c5a48)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
Docker has several capabilities enabled by default and some not.
It seems natural to follow this distinction in --cap-add and
--cap-drop.
Signed-off-by: Harald Albers <github@albersweb.de>
(cherry picked from commit 36d8b66cb9)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
When using `docker volume rm -f`, all errors were ignored,
and volumes where Purged, even if they were still in
use by a container.
As a result, repeated calls to `docker volume rm -f`
actually removed the volume.
The `-f` option was implemented to ignore errors
in case a volume was already removed out-of-band
by a volume driver plugin.
This patch changes the remove function to not
ignore "volume in use" errors if `-f` is used.
Other errors are still ignored as before.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 9d521a4d2f)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
Signed-off-by: John Howard <jhoward@microsoft.com>
This ensures that any compute processes in HCS are cleanedup
during daemon restore. Note Windows cannot (currently) reconnect
to containers on restore.
(cherry picked from commit f59593cbd1)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
When 567ef8e785 ("daemon: switch to 'ensure' workflow for AppArmor
profiles") was merged, it didn't correctly handle the exec path if
AppArmor profiles were deleted. Fix this by duplicating the
ensureDefaultApparmorProfile code in the exec code.
Fixes: 567ef8e785 ("daemon: switch to 'ensure' workflow for AppArmor profiles")
Signed-off-by: Aleksa Sarai <asarai@suse.de>
(cherry picked from commit 790a81ea9a)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
In https://github.com/torvalds/linux/commit/5ca3726 (released in v4.7-rc1) the
content of the `cpuacct.usage_percpu` file in sysfs was changed to include both
online and offline cpus. This broke the arithmetic in the stats helpers used by
`docker stats`, since it was using the length of the PerCPUUsage array as a
proxy for the number of online CPUs.
Add current number of online CPUs to types.StatsJSON and use it in the
calculation.
Keep a fallback to `len(v.CPUStats.CPUUsage.PercpuUsage)` so this code
continues to work when talking to an older daemon. An old client talking to a
new daemon will ignore the new field and behave as before.
Fixes#28941.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
(cherry picked from commit 115f91d757)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
Commit 87a53468b2 cherry-picked
changes into the 17.03 branch to make the client
skip auto-removing containers on API 1.25 and up.
Some changes got lost during that cherry-pick,
resulting in 17.03 clients to not fall back to
the old behavior when connecting to API version
1.24 or below.
This patch addresses this issue for the 17.03
branch by copying the `HostConfig.AutoRemove` property
to a local variable before it is overridden
in `ContainerCreate()`.
This change is not needed on "master" (17.04-dev),
which does not have this problem.
Thanks to Josh Hawn for finding this bug.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
remove 400 and 404 for get nodes endpoint and add 503 for secret update
(cherry picked from commit e8b92f154d)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
I found that sometimes tasks would end up in a rejected state when
trying to update them quickly. The problem was that Shutdown could fail
if called before the container was started. Instead of returning an
error in this case, Shutdown should succeed. This allows tasks to
progress to the "shutdown" state as expected.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
(cherry picked from commit 37b492ae1b)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
This fix tries to fix the issue raised in 21845. The issue with 21845
is that if multiple `--volumes-from` with the same destination has been
specified, then one volume will be overridden by the other. This will mess
up with volumes reference and prevent the overridden volume from
being removed at the end.
Issue 21845 was observed with `docker-compose` though it is possible to
emulate the same behavior with `docker` alone:
```
$ cat Dockerfile
FROM busybox
VOLUME ["/tmp/data"]
$ docker build -t vimage .
$ docker run --name=data1 vimage true
$ docker run --name=data2 vimage true
$ docker run --name=app --volumes-from=data1 --volumes-from=data2 -d busybox top
$ docker rm -f -v $(docker ps -aq)
$ docker volume ls
$ docker volume rm ...
```
NOTE: Second case:
```
$ cat Dockerfile
FROM busybox
VOLUME ["/tmp/data"]
$ docker build -t vimage .
$ docker run --name=data1 vimage true
$ docker run --name=data2 vimage true
$ docker run --name=app --volumes-from=data1 --volumes-from=data2 -v /tmp/data:/tmp/data -d busybox top
$ docker rm -f -v $(docker ps -aq)
$ docker volume ls
$ docker volume rm ...
```
NOTE: Third case: Combination of --volumes-from and `HostConfig.Mounts` (API only)
This fix tries to address the issue by return an error if duplicate
mount points was used with `--volumes-from`.
An integration test has been added.
This fix fixes 21845.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
(cherry picked from commit 9526e5c6ae)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
Make sure that the cursor value returned by followJournal() is the last
of the values returned by its goroutine's calls to drainJournal() by
waiting for it, rather than returning a value that may be superceded by
another if we're singalling the goroutine that it should exit by closing
a pipe.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
(cherry picked from commit d57c330617)
Signed-off-by: Victor Vieux <victorvieux@gmail.com>
