People have reported following issue with overlay
$ docker run -ti --name=foo -v /dev/:/dev fedora bash
$ docker cp foo:/bin/bash /tmp
$ exit container
Upon container exit, /dev/pts gets unmounted too. This happens because
docker cp volume mounts get propagated to /run/docker/libcontainer/....
and when container exits, it must be tearing down mount point under
/run/docker/libcontainerd/... and as these are "shared" mounts it
propagates events to /dev/pts and it gets unmounted too.
One way to solve this problem is to make sure "docker cp" volume mounts
don't become visible under /run/docker/libcontainerd/..
Here are more details of what is actually happening.
Make overlay home directory (/var/lib/docker/overlay) private mount when
docker starts and unmount it when docker stops. Following is the reason
to do it.
In fedora and some other distributions / is "shared". That means when
docker creates a container and mounts it root in /var/lib/docker/overlay/...
that mount point is "shared".
Looks like after that containerd/runc bind mounts that rootfs into
/runc/docker/libcontainerd/container-id/rootfs. And this puts both source
and destination mounts points in shared group and they both are setup
to propagate mount events to each other.
Later when "docker cp" is run it sets up container volumes under
/var/lib/dokcer/overlay/container-id/... And all these mounts propagate
to /runc/docker/libcontainerd/... Now mountVolumes() makes these new
mount points private but by that time propagation already has happened
and private only takes affect when unmount happens.
So to stop this propagation of volumes by docker cp, make
/var/lib/docker/overlay a private mount point. That means when a container
rootfs is created, that mount point will be private too (it will inherit
property from parent). And that means when bind mount happens in /runc/
dir, overlay mount point will not propagate mounts to /runc/.
Other graphdrivers like devicemapper are already doing it and they don't
face this issue.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: e076bccb458aeadab9380ce0636456ad6317a85f
Component: engine
link feature in docker0 bridge by default provides short-id as a
container alias. With built-in SD feature, providing a container
short-id as a network alias will fill that gap.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: ea531f061d3c511e376753f9863cb41f1b96d87e
Component: engine
Fixes#22030
Because the publisher uses this same value to all the
stats endpoints we need to make a copy of this as soon as we get it so
that we can make our modifications without it affecting others.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: d17ee4b506af842b2d9fe6f8736b4636e32db599
Component: engine
This patch did following:
1) Make filter check logic same as `docker ps ` filters
Right now docker container logic work as following:
when same filter used like below:
-f name=jack -f name=tom
it would get all containers name is jack or tom(it is or logic)
when different filter used like below:
-f name=jack -f id=7d1
it would get all containers name is jack and id contains 7d1(it is and logic)
It would make sense in many user cases, but it did lack of compliate filter cases,
like "I want to get containers name is jack or id=7d1", it could work around use
(get id=7d1 containers' name and get name=jack containers, and then construct the
final containers, they could be done in user side use shell or rest API)
2) Fix one network filter bug which could include duplicate result
when use -f name= -f id=, it would get duplicate results
3) Make id filter same as container id filter, which means match any string.
not use prefix match.
It is for consistent match logic
Closes: #21417
Signed-off-by: Kai Qiang Wu(Kennan) <wkqwu@cn.ibm.com>
Upstream-commit: f812b55692f5d50d427684216ad6c806bac5a702
Component: engine
The `Status` field is a `map[string]interface{}` which allows the driver to pass
back low-level details about the underlying volume.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 36a1c56cf555f8fe9ceabeebb8fc956e05863fc7
Component: engine
People have reported following problem.
- docker run -ti --name=foo -v /dev/:/dev/ fedora bash
- docker cp foo:/bin/bash /tmp
Once the cp operation is complete, it unmounted /dev/pts on the host. /dev/pts
is a submount of /dev/. This is completely unexpected. Following is the
reson for this behavior.
containerArchivePath() call mountVolumes() which goes through all the mounts
points of a container and mounts them in daemon mount namespace in
/var/lib/docker/devicemapper/mnt/<containerid>/rootfs dir. And once we have
extracted the data required, these are unmounted using UnmountVolumes().
Mounts are done using recursive bind (rbind). And these are unmounted using
lazy mount option on top level mount. (detachMounted()). That means if there
are submounts under top level mounts, these mount events will propagate and
they were "shared" mounts with host, it will unmount the submount on host
as well.
For example, try following.
- Prepare a parent and child mount point.
$ mkdir /root/foo
$ mount --bind /root/foo /root/foo
$ mount --make-rshared /root/foo
- Prepare a child mount
$ mkdir /root/foo/foo1
$ mount --bind /root/foo/foo1 /root/foo/foo1
- Bind mount foo at bar
$ mkdir /root/bar
$ mount --rbind /root/foo /root/bar
- Now lazy unmount /root/bar and it will unmount /root/foo/foo1 as well.
$ umount -l /root/bar
This is not unintended. We just wanted to unmount /root/bar and anything
underneath but did not have intentions of unmounting anything on source.
So far this was not a problem as docker daemon was running in a seprate
mount namespace where all propagation was "slave". That means any unmounts
in docker daemon namespace did not propagate to host namespace.
But now we are running docker daemon in host namespace so that it is possible
to mount some volumes "shared" with container. So that if container mounts
something it propagates to host namespace as well.
Given mountVolumes() seems to be doing only temporary mounts to read some
data, there does not seem to be a need to mount these shared/slave. Just
mount these private so that on unmount, nothing propagates and does not
have unintended consequences.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: cacd4007776672e918162936d8846eb51a5300e6
Component: engine
Running on kernel versions older than 3.10 has not been
supported for a while (as it's known to be unstable).
With the containerd integration, this has become more
apparent, because kernels < 3.4 don't support PR_SET_CHILD_SUBREAPER,
which is required for containerd-shim to run.
Change the previous "warning" to a "fatal" error, so
that we refuse to start.
There's still an escape-hatch for users by setting
"DOCKER_NOWARN_KERNEL_VERSION=1" so that they can
run "at their own risk".
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 51b23d88422918c24291f5876df35f91b23a446a
Component: engine
Using new methods from engine-api, that make it clearer which element is
required when consuming the API.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: b9c94b70bf2f703f260844b3862a61f93dee6337
Component: engine
If contaner start fail of (say) "command not found", the container
actually didn't start at all, we shouldn't log start and die event for
it, because that doesnt actually happen.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 5548966c37147875fb5e07f4ba7f633dd882c782
Component: engine
This change allow to filter events that happened in the past
without waiting for future events. Example:
docker events --since -1h --until -30m
Signed-off-by: David Calavera <david.calavera@gmail.com>
Upstream-commit: 55053d3537100eaeaad9c83b43e31f22d14fde7b
Component: engine
In TP5, Hyper-V containers need all image files ACLed so that the virtual
machine process can access them. This was fixed post-TP5 in Windows, but
for TP5 we need to explicitly add these ACLs.
Signed-off-by: John Starks <jostarks@microsoft.com>
Upstream-commit: 6f8878872f8782d4300faeb80413c8c60f56cff1
Component: engine
Implements a `CachedPath` function on the volume plugin adapter that we
call from the volume list function instead of `Path.
If a driver does not implement `CachedPath` it will just call `Path`.
Also makes sure we store the path on Mount and remove the path on
Unmount.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 9e6b1852a78eda6ed2cb255d6be8a0d0e5a5ca40
Component: engine
This patch will allow users to specify namespace specific "kernel parameters"
for running inside of a container.
Signed-off-by: Dan Walsh <dwalsh@redhat.com>
Upstream-commit: 9caf7aeefd23263a209c26c8439d26c147972d81
Component: engine
Docker stats is not working when a container is using another container's network.
Upstream-commit: d648d40ace5440d1a3c8c9dbc1115d40ebcbae3c
Component: engine
Other places referring to the same configuration, including docs, have
the correct spelling.
Signed-off-by: Rodolfo Carvalho <rhcarvalho@gmail.com>
Upstream-commit: fee7e7c7a31023be9f0c26608e6cbd4e8a97d25b
Component: engine
For TP5, the utility VM for Hyper-V containers is embedded in the base
layer's contents.
Signed-off-by: John Starks <jostarks@microsoft.com>
Upstream-commit: c70f153f52c8ca75a395d4dc1c4a5759871ada19
Component: engine
If aufs is already modprobe'd but we are in a user namespace, the
aufs driver will happily load but then get eperm when it actually tries
to do something. So detect that condition.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Upstream-commit: 2a71f28a4e1167dee32aa16ddbc819c9d9e77f71
Component: engine
Currently if you restart docker daemon, all the containers with restart
policy `on-failure` regardless of its `RestartCount` will be started,
this will make daemon cost more extra time for restart.
This commit will stop these containers to do unnecessary start on
daemon's restart.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 51e42e6ee01eb4b5c8c7678e2fc7be0f13ef6a68
Component: engine
This fix tries to fix the issue in #21848 where `docker stats` will not correctly
display the container stats in case the container reuse another container's
network stack.
The issue is that when `stats` is performed, the daemon will check for container
network setting's `SandboxID`. Unfortunately, for containers that reuse another
container's network stack (`NetworkMode.IsConnected()`), SandboxID is not assigned.
Therefore, the daemon thinks the id is invalid and remote API will never return.
This fix tries to resolve the SandboxID by iterating through connected containers
and identify the appropriate SandboxID.
A test case for `stats` remote API has been added to check if `stats` will return
within the timeout.
This fix fixes#21848.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: faf2b6f7aaca7f9ef400e227921b8125590fc9e5
Component: engine
