This fix tries to addess the issue in #21956 where `docker inspect`
will overwrite the log config options with default option even when
the `--log-driver` is not empty and `--log-opt` is empty. In this
situation, `docker inspect` and `docker run` is different.
With the introduction of #21153, the `HostConfig` will always have
the correct log-driver and log-opt values.
However, the previous processing of `docker inspect` was not updated
after the change in #21153. This results in the incorrect behavior.
This fix addresses this issue by updating `docker inspect` to conform
to #21153 so the the behavior of `docker inspect` and `docker run` is
consistent.
A integration test has been added to cover this fix.
This fix fixes#21956. This fix is related to #21153.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 4b5404f15ed2944ca2d994f52618338c52611352
Component: engine
This flag can be set on disk if the daemon were to crash or error out
while trying to remove container in which case subsequent tries to
delete the container would all fail.
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Upstream-commit: ce724731973159a4fcedf16d0996571684cc3843
Component: engine
This add a new filter to 'docker network ls'
to allow filtering by driver-name.
Contrary to "ID" and "name" filters, this
filter only supports an *exact* match.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 23e418b6c966a43a463a064053ce0c741b8e5159
Component: engine
For every docker load and save operations, it would log related
image events.
Signed-off-by: Kai Qiang Wu(Kennan) <wkqwu@cn.ibm.com>
Upstream-commit: 06561057103441fe176910e12674d998b8561b75
Component: engine
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Set up the mount label in the spec for a container
Signed-off-by: Mrunal Patel <mrunalp@gmail.com>
Upstream-commit: e0f98c698b49e3790fe63bff611eeda6f5b46055
Component: engine
This change enables the workflow of finishing installing Windows OS updates in the container after it has completed running, via a special servicing container.
Signed-off-by: Stefan J. Wernli <swernli@microsoft.com>
Upstream-commit: da92dad59f76421a22a955d2aed25bfeb4562385
Component: engine
This fix tries to address the issue raised in #22271 where
relative symlinks don't work with --device argument.
Previously, the symlinks in --device was implemneted (#20684)
with `os.Readlink()` which does not resolve if the linked
target is a relative path. In this fix, `filepath.EvalSymlinks()`
has been used which will reolve correctly with relative
paths.
An additional test case has been added to the existing
`TestRunDeviceSymlink` to cover changes in this fix.
This fix is related to #13840 and #20684, #22271.
This fix fixes#22271.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 632b314b239d1cd5e2498f198503a2983233a9f4
Component: engine
commit 20a038eca68e4188e1cd812293aea8cb220cf08f changed
daemon configuration reloading to check if a value
was actually set, however, it checked for the wrong
property ("label" instead of "labels"), which resulted
in the labels only to be loaded from daemon.json if both
a "label" -and- a "labels" property was present.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 455858fc70e3b752fb2495bbdda368613e6587c2
Component: engine
2.windows can use cors, too
3.remove function setPlatformServerConfig
Signed-off-by: allencloud <allen.sun@daocloud.io>
Upstream-commit: 2feb88cbd391027fddf514496a5a825848c670ab
Component: engine
There was an error in validation logic before, should use period
instead of quota, and also add check for negative
number here, if not with that, it would had cpu.cfs_period_us: invalid argument
which is not good for users.
Signed-off-by: Kai Qiang Wu(Kennan) <wkqwu@cn.ibm.com>
Upstream-commit: 62cb06a6c1db5599f1f5b9b95b298be83c509860
Component: engine
This makes sure fsdiff doesn't try to unmount things that shouldn't be.
**Note**: This is intended as a temporary solution to have as minor a
change as possible for 1.11.1. A bigger change will be required in order
to support container re-attach.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 7342060b070df67481f8da4f394a57cac1671d56
Component: engine
Right now there is no way to know what's the minimum free space threshold
daemon is applying. It would be good to export it through docker info and
then user knows what's the current value. Also this could be useful to
higher level management tools which can look at this value and setup their
own internal thresholds for image garbage collection etc.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 55a9b8123d7e89692b5c25c846cf6707a8ce463a
Component: engine
This fix tries to fix the http panics caused by container deletion
with empty names in #22210.
The issue was because when an empty string was passed, `GetByName()`
tried to access the first element of the name string without checking
the length. A length check has been added.
A test case for #22210 has been added.
This fix fixes#22210.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 9d8071a74db20556d0fc1b6ef3270326b3583de9
Component: engine
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
