In cases there are failures in task start, swarmkit might be trying to
restart the task again in the same node which might keep failing. This
creates a race where when a failed task is getting removed it might
remove the associated network while another task for the same service
or a different service but connected to the same network is proceeding
with starting the container knowing that the network is still
present. Fix this by reacting to `ErrNoSuchNetwork` error during
container start by trying to recreate the managed networks. If they
have been removed it will be recreated. If they are already present
nothing bad will happen.
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
Upstream-commit: 117cef5e9766d6ba228770c225e816c6afd16ff8
Component: engine
Unlike `docker run -v..`, `docker service create --mount`
does not allow bind-mounting non-existing host paths.
This adds validation for the specified `source`, and
produces an error if the path is not found on the
host.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 84d5ab96ef33355e65f5c31210eb1777db372c52
Component: engine
Before this, container's auto-removal after exit is done in a goroutine,
this commit will get ContainerRm out of the goroutine.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 1537dbe2d617013c94aa42c28744feb07a09fb63
Component: engine
If AutoRemove is set, wait until client get `destroy` events, or get
`detach` events that implies container is detached but not stopped.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 6dd8e10d6ed7a7371c5c1824ad58c4403a7b3bfd
Component: engine
`--rm` is a client side flag which caused lots of problems:
1. if client lost connection to daemon, including client crash or be
killed, there's no way to clean garbage container.
2. if docker stop a `--rm` container, this container won't be
autoremoved.
3. if docker daemon restart, container is also left over.
4. bug: `docker run --rm busybox fakecmd` will exit without cleanup.
In a word, client side `--rm` flag isn't sufficient for garbage
collection. Move the `--rm` flag to daemon will be more reasonable.
What this commit do is:
1. implement a `--rm` on daemon side, adding one flag `AutoRemove` into
HostConfig.
2. Allow `run --rm -d`, no conflicting `--rm` and `-d` any more,
auto-remove can work on detach mode.
3. `docker restart` a `--rm` container will succeed, the container won't
be autoremoved.
This commit will help a lot for daemon to do garbage collection for
temporary containers.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 3c2886d8a45d8e79b00ab413d91f1af871b58d0a
Component: engine
This fix tries to address the issue raised in #23498 to allow unset
`--entrypoint` in `docker run` or `docker create`.
This fix checks the flag `--entrypoint` and, in case `--entrypoint=` (`""`)
is passed, unset the Entrypoint during the container run.
Additional integration tests have been created to cover changes in this fix.
This fix fixes#23498.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: c8d3ee80933d6337382fb4a52d90835e263c1aaf
Component: engine
This fix tries to address the issue raised in #23528 where
docker labels caused journald log error because journald
has special requirements on field names.
This fix addresses this issue by sanitize the labels per
requirements of journald.
Additional unit tests have been added to cover the changes.
This fix fixes#23528.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 9528ea930cdb90f906230a6d4cab179001255927
Component: engine
Only consider netlink "device" interfaces in address autodetection on Linux
Upstream-commit: acbac04c4bddb6861155ebdb28df1c19b50e5bdc
Component: engine
This fix tries to address the issue raised in 25374 where the
output of `docker ps --filter` is in random order and
not deterministic.
This fix sorts the list of containers by creation time so that the
output is deterministic.
An integration test has been added.
This fix fixes 25374.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 3f971335463b99a7caedcf597ffc544845b37a21
Component: engine
- This automatically rules out bridges and other non system
created interfaces
Signed-off-by: Alessandro Boch <aboch@docker.com>
Upstream-commit: 8f7d3a43807890e690c31e33dad3764911e1491f
Component: engine
Problem Description:
An example scenario that involves deferred removal
1. A new base image gets created (e.g. 'docker load -i'). The base device is activated and
mounted at some point in time during image creation.
2. While image creation is in progress, a privileged container is started
from another image and the host's mount name space is shared with this
container ('docker run --privileged -v /:/host').
3. Image creation completes and the base device gets unmounted. However,
as the privileged container still holds a reference on the base image
mount point, the base device cannot be removed right away. So it gets
flagged for deferred removal.
4. Next, the privileged container terminates and thus its reference to the
base image mount point gets released. The base device (which is flagged
for deferred removal) may now be cleaned up by the device-mapper. This
opens up an opportunity for a race between a 'kworker' thread (executing
the do_deferred_remove() function) and the Docker daemon (executing the
CreateSnapDevice() function).
This PR cancel the deferred removal, if the device is marked for it. And reschedule the
deferred removal later after the device is resumed successfully.
Signed-off-by: Shishir Mahajan <shishir.mahajan@redhat.com>
Upstream-commit: 0e633ee14aca32480ac4735675222c35f4e11d8c
Component: engine
Fixes: #25073
Update kernel memory on running containers without initialized
is forbidden only on kernel version older than 4.6.
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
Upstream-commit: da5d66fb70064b093f73cc31eddb7e8285048161
Component: engine
This is intended as a minor fix for 1.12.1 so that task creation doesn't
do unexpected things when the user supplies erroneous paths.
In particular, because we're currently using hostConfig.Binds to setup
mounts, if a user uses an absolute path for a volume mount source, or a
non-absolute path for a bind mount source, the engine will do the
opposite of what the user requested since all absolute paths are
treated as binds and all non-absolute paths are treated as named
volumes.
Fixes#25253
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 38f8b0eb10725c40fb3c7e0719accd240cd39e22
Component: engine
This fix tries to improve error messages when IP address
autodetection fails, as is specified in 25141.
Previously, error messages only indicate that multiple IPs
exist when autodetection fails. In this fix, if one
interface consists of multiple addresses or multiple
interfaces consist of addresses, the error messages output
the address names and interface names so that end user could
take notice.
This fix is verified manually.
When multiple addresses exist on multiple interfaces:
```
$ sudo docker swarm init
Error response from daemon: could not choose an IP address
to advertise since this system has multiple addresses on different
interfaces (192.168.186.128 on ens33 and 192.168.100.199 on eth10)
- specify one with --advertise-addr
```
When multiple addresses exist on single interface:
```
$ sudo docker swarm init
Error response from daemon: could not choose an IP address
to advertise since this system has multiple addresses
on interface ens33 (192.168.186.128 and 192.168.55.199)
- specify one with --advertise-addr
```
This fix fixes 25141.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 59db01049ac6a8e54490565dc44661f780c13734
Component: engine
Windows base layers are no longer the special "layers+base" type, so we can remove all the special handling for that.
Signed-off-by: Stefan J. Wernli <swernli@microsoft.com>
Upstream-commit: f342b27145d8f5af27cd5de1501551af275e899b
Component: engine
A kernel may support any of these, but an admin may have unmounted
certain cgroups, so let's include that possibility in the error so
as to avoid users thinking they have a kernel issue.
Signed-off-by: Christy Perez <christy@linux.vnet.ibm.com>
Upstream-commit: 846f33f93d9cd32ed90680d106cd5d9eb96b0ddd
Component: engine
join-tokens are not needed for this endpoint, and should not be as part
of /info
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
(cherry picked from commit d8f3b3f006629c5c1368eca96bcd5bda2a54acd7)
Upstream-commit: 96b2a6e548bc3abf0f0a505ee020d2fe1e8997de
Component: engine
