fixes#25766
If a container's AutoRemove is enabled, client will wait until it's
removed after container exits, this is implemented based on "destroy"
event.
Currently an "AutoRemove" container will report "destroy" event to
notify a hanging client to exit before all volumes are removed, this is
wrong, we should wait container until everything is cleaned up.
Signed-off-by: Zhang Wei <zhangwei555@huawei.com>
Upstream-commit: 4df77c11e065bf96b04fc0328a7e7600a2e64937
Component: engine
It is safe to set other namespaces to host when user ns is set to host
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Upstream-commit: 3c3d2bf85229f9ca4879a24072762477e96c4344
Component: engine
If we are running in a user namespace, don't try to mknod as
it won't be allowed. libcontainer will bind-mount the host's
devices over files in the container anyway, so it's not needed.
The chrootarchive package does a chroot (without mounting /proc) before
its work, so we cannot check /proc/self/uid_map when we need to. So
compute it in advance and pass it along with the tar options.
Signed-off-by: Serge Hallyn <serge.hallyn@ubuntu.com>
Upstream-commit: 617c352e9225b1d598e893aa5f89a8863808e4f2
Component: engine
During image pulls on docker service create, logs will only show status
updates and updates every 1 second on long-running actions like
downloading and extracting. Adds golang.org/x/time/rate as dependency.
Ports docker/swarmkit#1352 to docker/docker.
Signed-off-by: Drew Erny <drew.erny@docker.com>
Upstream-commit: fa0054a3eb0363526d34fb4ac912cab30044f3d7
Component: engine
Use `LabeledVolume` interface type instead of manual interface.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 6d787dae1ae3cd4f2ca062b67592158597f9d40e
Component: engine
Since we added labels for volume, it is desired to have
filter support label for volume
Closes: #21416
Signed-off-by: Kai Qiang Wu(Kennan) <wkqwu@cn.ibm.com>
Upstream-commit: 1a72934cd5cb369f75e7bd5714eb579a053b95a9
Component: engine
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
