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>
- When a network is created with the null ipam driver, docker api server
thread will deference a nil pointer on `docker network ls` and on
`docker network inspect <nw>`. This because buildIpamResource()
assumes a gateway address is always present, which is not correct.
Signed-off-by: Alessandro Boch <aboch@tetrationanalytics.com>
(cherry picked from commit beebfc0cf6240c8af511eb4d7e29314c8de6ddf2)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
When running `docker stack rm <some stack>` against an older daemon,
a warning was printed for "configs" being ignored;
WARNING: ignoring "configs" (requires API version 1.30, but the Docker daemon API version is 1.26)
Given that an old daemon cannot _have_ configs, there should not be
a need to warn, or _attempt_ to remove these resources.
This patch removes the warning, and skips fetching (and removing)
configs.
A check if _secrets_ are supported by the daemon is also added,
given that this would result in an error when attempted against
an older (pre 1.13) daemon.
There is one situation where this could lead to secrets or
configs being left behind; if the client is connecting to a
daemon that _does_ support secrets, configs, but the API version
is overridden using `DOCKER_API_VERSION`, no warning is printed,
and secrets and configs are not attempted to be removed.
Given that `DOCKER_API_VERSION` is regarded a feature for
debugging / "power users", it should be ok to ignore this.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 2429f15672)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 4735c7663201ce1bf618e2aa505d7813a331be3f)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The `is-task` filter was only documented in the usage
section, but this section is not used in the documentation.
This patch adds the missing filter, synchronises the
man page source, and does some slight rephrasing
and reformatting of the filters.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 46064f33f4)
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>
