Commit 077f08bf54dc89d382cbcbd797b2bd7c4867151d
temporarily switch etcd to a fork, pending a
pull-request to be merged, and a new release
that contains the change.
The pull request was merged, and included in
etcd v3.2.0
This patch bumps etcd to v3.2.1, which contains
some bug-fixes on top of v3.2.0
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: cbc480a40cb22653ac647a8d24957a0c33e3bffe
Component: engine
Do not allow sharing of container network with hyperv containers
Signed-off-by: Madhan Raj Mookkandy <madhanm@microsoft.com>
Upstream-commit: 349913ce9fde34d8acd08fad5ce866401f4d135e
Component: engine
This script is part of the Docker product,
and no longer maintained in this repository.
The script has been updated to install Docker CE
packages from https://download.docker.com, and is
now located in the https://github.com/docker/docker-install
repository.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: e038f9f81f871237e9ec7a2188eb6b401bdd8809
Component: engine
Enables other subsystems to watch actions for a plugin(s).
This will be used specifically for implementing plugins on swarm where a
swarm controller needs to watch the state of a plugin.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 72c3bcf2a533a827402945e3a55872e2db4fb024
Component: engine
docker run --name=test ubuntu /bin/sh -c "cd /tmp && echo hi > a && ln a b" && docker cp test:/tmp tmp_
test
link /root/tmp/a /root/tmp_/b: no such file or directory
Signed-off-by: yangshukui <yangshukui@huawei.com>
Upstream-commit: d58ffa0364c04d03a8f25704d7f0489ee6cd9634
Component: engine
Before this patch, a log reader is able to block all log writes
indefinitely (and other operations) by simply opening the log stream and
not consuming all the messages.
The reason for this is we protect the read stream from corruption by
ensuring there are no new writes while the log stream is consumed (and
caught up with the live entries).
We can get around this issue because log files are append only, so we
can limit reads to only the section of the file that was written to when
the log stream was first requested.
Now logs are only blocked until all files are opened, rather than
streamed to the client.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: e2209185ed1c959131d4068ec7fc93e194dc0802
Component: engine
When run `docker rename <container-id> new_name` concurrently, every operation will release
container's old name. So container will have multi new names reserve in nameIndex.
Signed-off-by: Yang Pengfei <yangpengfei4@huawei.com>
Upstream-commit: cc2340689c431504689d01c9516b3a340b2e8dbc
Component: engine
Go 1.9 (golang/go@66b5a2f) removed file type bits from
archive/tar.FileInfoHeader().
This commit ensures file type bits are filled even on Go 1.9 for
compatibility.
Signed-off-by: Akihiro Suda <suda.akihiro@lab.ntt.co.jp>
Upstream-commit: 1a451d9a7bb9cd7d437b42d4e73b0560fbf84348
Component: engine
COmmit 0307fe1a0bcdc02583a24add41eb783c117bad8c added
a new `DataPathAddr` property to the swarm/init and swarm/join
endpoints. This property was not yet added to the
documentation.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: c79c16910c0f3d6e88f2dc6ef609ecc3b02ccef9
Component: engine
Do not set a default value for swappiness as the default value should be
`nil`
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Upstream-commit: 9d87e6e0fb799d6ef3bb9a97bc523f8d343b5fb3
Component: engine
Because we use our own logging callbacks in order to use libdm
effectively, it is quite difficult to debug complicated devicemapper
issues (because any warnings or notices from libdm are muted by our own
callback function). e07d3cd9a ("devmapper: Fix libdm logging") further
reduced the ability of this debugging by only allowing _LOG_FATAL errors
to be passed to the output.
Unfortunately libdm is very chatty, so in order to avoid making the logs
even more crowded, add a dm.libdm_log_level storage option that allows
people who are debugging the lovely world of libdm to be able to dive in
without recompiling binaries.
The valid values of dm.libdm_log_level map directly to the libdm logging
levels, and are in the range [2,7] as of the time of writing with 7
being _LOG_DEBUG and 2 being _LOG_FATAL. The default is _LOG_FATAL.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Upstream-commit: 198f83bba120c6c9bda679d33a55acab6cc9f33d
Component: engine
LogInit used to act as a manual way of registering the *necessary*
pkg/devicemapper logging callbacks. In addition, it was used to split up
the logic of pkg/devicemapper into daemon/graphdriver/devmapper (such
that some things were logged from libdm).
The manual aspect of this API was completely non-sensical and was just
begging for incorrect usage of pkg/devicemapper, so remove that semantic
and always register our own libdm callbacks.
In addition, recombine the split out logging callbacks into
pkg/devicemapper so that the default logger is local to the library and
also shown to be the recommended logger. This makes the code
substantially easier to read. Also the new DefaultLogger now has
configurable upper-bound for the log level, which allows for dynamically
changing the logging level.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Upstream-commit: cfd39e8d6d79eee8a71fbe6820dd67babf05d951
Component: engine
e07d3cd9a ("devmapper: Fix libdm logging") removed all of the callers of
DmLogInitVerbose, but we still kept around the wrapper. However, the
libdm dm_log_init_verbose API changes the verbosity of the *default*
libdm logger. Because pkg/devicemapper internally *relies* on using
logging callbacks to understand what errors were encountered by libdm,
this wrapper is useless (it only makes sense for the default logger
which we do not user).
Any user not inside Docker of this function almost certainly was not
using this API correctly, because pkg/devicemapper will misbehave if our
logging callbacks were not registered.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Upstream-commit: c654147f0635736fff0035ecdfa53a41c7fad0d0
Component: engine
This limit is unecessary and can lead to the truncation of long libdm
logs (which is quite annoying).
Fixes: b440ec013 ("device-mapper: Move all devicemapper spew to log through utils.Debugf().")
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Upstream-commit: 63328c6882c3d1f54c66499ef9963adfbf1883f0
Component: engine
Description:
1. start a container with restart=always.
`docker run -d --restart=always ubuntu sleep 3`
2. container init process exits.
3. use `docker pause <id>` to pause this container.
if the pause action is before cgroup data is removed and after the init process died.
`Pause` operation will success to write cgroup data, but actually do not freeze any process.
And then docker received pause event and stateExit event from
containerd, the docker state will be Running(paused), but the container
is free running.
Then we can not remove it, stop it , pause it and unpause it.
Signed-off-by: Wentao Zhang <zhangwentao234@huawei.com>
Upstream-commit: fe1b4cfba6320793373c5397641d743d9fe94cf8
Component: engine
the filemode should be 0640 but not 06400
Signed-off-by: Lei Jitang <leijitang@huawei.com>
Upstream-commit: 96ea8eaa1592856e0829c3465e64f93911d3e389
Component: engine
This dependency was temporarily forked, but
the fork was removed in db37a86d37431a1d82505cf6adc91a5d91dad146.
This patch removes the comment
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: fe877c2b959b60d953ad4b2d3eeda377add575a5
Component: engine
The name/ID relationships are maintained separately from the memdb and
can be out of sync from any particular memdb snapshot. If a container
does not exist in the memdb, we must accept this as normal and not fail
the listing. This is consistent with what the code used to do before
memdb was introduced.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: d257a63fb6a2ad0c2369981914544add389917bf
Component: engine
Recently, it's become necessary to build dynbinaries on certain
distributions, so make it easier for users to build dynbinaries. It
looks like this was just an oversight when we added dynbinary builds.
Signed-off-by: Aleksa Sarai <asarai@suse.de>
Upstream-commit: c81255c9c0314b81ab27f6afd7646cdd259e6495
Component: engine
There have been some cases where umount, a device can be busy for a very
short duration. Maybe its udev rules, or maybe it is runc related races
or probably it is something else. We don't know yet.
If deferred removal is enabled but deferred deletion is not, then for the
case of "docker run -ti --rm fedora bash", a container will exit, device
will be deferred removed and then immediately a call will come to delete
the device. It is possible that deletion will fail if device was busy
at that time.
A device can't be deleted if it can't be removed/deactivated first. There
is only one exception and that is when deferred deletion is on. In that
case graph driver will keep track of deleted device and try to delete it
later and return success to caller.
Always make sure that device deactivation is synchronous when device is
being deleted (except the case when deferred deletion is enabled).
This should also take care of small races when device is busy for a short
duration and it is being deleted.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 36cb6efebc599900b691e206fb9e99d3aa2fb9a3
Component: engine
Before this patch, if the plugin's `config.json` is successfully removed
but the main plugin state dir could not be removed for some reason (e.g.
leaked mount), it will prevent the daemon from being able to be
restarted.
This patches changes this to atomically remove the plugin such that on
daemon restart we can detect that there was an error and re-try. It also
changes the logic so that it only logs errors on restore rather than
erroring out the daemon.
This also removes some code which is now duplicated elsewhere.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 11cf394e5ea964636294a219872b188fe5bdf4dd
Component: engine