Description:
Kill docker-containerd continuously, and use kill -SIGUSR1 <dockerpid>
to check docker callstacks. And we will find that event
handler: startEventsMonitor or handleEventStream will exit.
This will only happen when system is busy, containerd need more time to
startup, and the monitor gorotine maybe exit.
Signed-off-by: Wentao Zhang <zhangwentao234@huawei.com>
(cherry picked from commit 02ce73f62e73e78a4ec29b29fb2ba552221fe885)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This prevents mounts in the plugins dir from leaking into other
namespaces which can prevent removal (`device or resource busy`),
particularly on older kernels.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 0c2821d6f2de692d105e50a399daa65169697cca)
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
So we can use it at will
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
(cherry picked from commit 533a843393bd7c3674074ec9af73c8e666fc7484)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
`ConnectToNetwork` is modfying the container but is not locking the
object.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit 4d0888e32bccfd8c0f27a7b66b2a5607d42e2698)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Original PR message:
releaseableLayer includes automatic handling for creating a read/write layer and mounting it on a call to Mount(), but then does not correspondingly unmount the layer before trying to delete it, which will fail for some graphdrivers. Commit on a releaseable layer also leaks the tarstream for the layer. To fix this, the stream close is deferred in Commit and releaseRWLayer now correctly handles unmounting the layer before trying to delete it. In addition, the changes include better error handling in Release() to make sure that errors are returned to the caller for failures on read/write layers instead of being ignored.# Please enter the commit message for your changes. Lines starting
Cherry-Pick note:
This version of the change was edited to merge with docker-ce 17.06, which did not include the releasableLayer.Commit code, requiring that part of the merge to be removed.
(cherry picked from commit 1d457999c4540aacda68f834bdb3c6f220ce3fd5)
Signed-off-by: Stefan Wernli <swernli@ntdev.microsoft.com>
Starting 17.06 swarm service create supports service creates with predefined
networks like host and bridge. Due to the nature of the feature, swarm manager
has a swarm scope predefined networks in addition to local scoped
predefined networks on all nodes. However network inspects for swarm scoped
predefined networks was not possible. The fix adds support for network inspect
for swarm scoped predefined networks.
Signed-off-by: Abhinandan Prativadi <abhi@docker.com>
(cherry picked from commit 5bfefb2d3662fa066ddf0d0e10cac93ee70f7ae8)
Signed-off-by: Abhinandan Prativadi <abhi@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit fc48b5529dca3907ade273921a14906be796e333)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The "until" filter is supported by all object types, except for
volumes.
Before this patch, the "until" filter would attempted to be used for the volume
prune endpoint, resulting in an error being returned by the daemon, and
further prune endpoints (networks, images) to be skipped.
$ docker system prune --filter until=24h --filter label=label.foo=bar
WARNING! This will remove:
- all stopped containers
- all volumes not used by at least one container
- all networks not used by at least one container
- all dangling images
Are you sure you want to continue? [y/N] y
Error response from daemon: Invalid filter 'until'
Calling POST /v1.30/containers/prune?filters=%7B%22label%22%3A%7B%22label.foo%3D%3Dbar%22%3Atrue%7D%2C%22until%22%3A%7B%2224h%22%3Atrue%7D%7D
Calling POST /v1.30/volumes/prune?filters=%7B%22label%22%3A%7B%22label.foo%3D%3Dbar%22%3Atrue%7D%2C%22until%22%3A%7B%2224h%22%3Atrue%7D%7D
Handler for POST /v1.30/volumes/prune returned error: Invalid filter 'until'
Error response from daemon: Invalid filter 'until'
With this patch, an error is produced instead, preventing "partial" prune.
$ docker system prune --filter until=24h --filter label=foo==bar --volumes
ERROR: The "until" filter is not supported with "--volumes"
Note that `docker volume prune` does not have this problem, and produces an
error if the `until` filter is used;
$ docker volume prune --filter until=24h
WARNING! This will remove all volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Error response from daemon: Invalid filter 'until'
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 3c095dc546)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Justin Menga <justin.menga@gmail.com>
(cherry picked from commit 0fd5a0bab79f20f910cb7551ec34158a32e05f5a)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Do not change pause state when restoring container's
status, or status in docker will be different with
status in runc.
Signed-off-by: Fengtu Wang <wangfengtu@huawei.com>
(cherry picked from commit 977c4046fd2147d7c04f4b513a94138013ca0dd6)
Signed-off-by: Andrew Hsu <andrewhsu@docker.com>
Specifically, none of the graphdrivers are supposed to return a
not-exist type of error on remove (or at least that's how they are
currently handled).
Found that AUFS still had one case where a not-exist error could escape,
when checking if the directory is mounted we call a `Statfs` on the
path.
This fixes AUFS to not return an error in this case, but also
double-checks at the daemon level on layer remove that the error is not
a `not-exist` type of error.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
(cherry picked from commit d42dbdd3d48d0134f8bba7ead92a7067791dffab)
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
