There is no case which would resolve in this error. The root user always exists, and if the id maps are empty, the default value of 0 is correct.
Signed-off-by: Daniel Nephin <dnephin@docker.com>
This patch adds the untilRemoved option to the ContainerWait API which
allows the client to wait until the container is not only exited but
also removed.
This patch also adds some more CLI integration tests for waiting for a
created container and waiting with the new --until-removed flag.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Handle detach sequence in CLI
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Update Container Wait Conditions
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Apply container wait changes to API 1.30
The set of changes to the containerWait API missed the cut for the
Docker 17.05 release (API version 1.29). This patch bumps the version
checks to use 1.30 instead.
This patch also makes a minor update to a testfile which was added to
the builder/dockerfile package.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Remove wait changes from CLI
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Address minor nits on wait changes
- Changed the name of the tty Proxy wrapper to `escapeProxy`
- Removed the unnecessary Error() method on container.State
- Fixes a typo in comment (repeated word)
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Use router.WithCancel in the containerWait handler
This handler previously added this functionality manually but now uses
the existing wrapper which does it for us.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Add WaitCondition constants to api/types/container
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Address more ContainerWait review comments
- Update ContainerWait backend interface to not return pointer values
for container.StateStatus type.
- Updated container state's Wait() method comments to clarify that a
context MUST be used for cancelling the request, setting timeouts,
and to avoid goroutine leaks.
- Removed unnecessary buffering when making channels in the client's
ContainerWait methods.
- Renamed result and error channels in client's ContainerWait methods
to clarify that only a single result or error value would be sent
on the channel.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Move container.WaitCondition type to separate file
... to avoid conflict with swagger-generated code for API response
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Address more ContainerWait review comments
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
This patch consolidates the two WaitStop and WaitWithContext methods
on the container.State type. Now there is a single method, Wait, which
takes a context and a bool specifying whether to wait for not just a
container exit but also removal.
The behavior has been changed slightly so that a wait call during a
Created state will not return immediately but instead wait for the
container to be started and then exited.
The interface has been changed to no longer block, but instead returns
a channel on which the caller can receive a *StateStatus value which
indicates the ExitCode or an error if there was one (like a context
timeout or state transition error).
These changes have been propagated through the rest of the deamon to
preserve all other existing behavior.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Some methods need to get a container *and* validate some conditon on
these (is the container running, …). The CheckContainer allows
to do that and helps remove some duplication.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
This fix fixes issue raised in 29492 where it was not
possible to specify a default `--default-shm-size` in daemon
configuration for each `docker run``.
The flag `--default-shm-size` which is reloadable, has been
added to the daemon configuation.
Related docs has been updated.
This fix fixes 29492.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
use secret store interface instead of embedded secret data into container
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
- use Filters instead of Filter for secret list
- UID, GID -> string
- getSecrets -> getSecretsByName
- updated test case for secrets with better source
- use golang.org/x/context instead of context
- for grpc conversion allocate with make
- check for nil with task.Spec.GetContainer()
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
- fix lint issues
- use errors pkg for wrapping errors
- cleanup on error when setting up secrets mount
- fix erroneous import
- remove unneeded switch for secret reference mode
- return single mount for secrets instead of slice
Signed-off-by: Evan Hazlett <ejhazlett@gmail.com>
This PR adds support for running regular containers to be connected to
swarm mode multi-host network so that:
- containers connected to the same network across the cluster can
discover and connect to each other.
- Get access to services(and their associated loadbalancers)
connected to the same network
Signed-off-by: Jana Radhakrishnan <mrjana@docker.com>
This fix tries to address the issue raised in 26220 where
disconnecting a container from network does not work if
the network id (instead of network name) has been specified.
The issue was that internally when trying to disconnecting
a contaienr fromt the network, the originally passed network
name or id has been used.
This fix uses the resolved network name (e.g., `bridge`).
An integration test has been added to cover the changes.
This fix fixes 26220.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
There are cases such as migrating from classic overlay network to the
swarm-mode networking (without kv-store), such a mechanism to allow
disconnecting a container even when a network isnt available will be
useful.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
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>
link feature in docker0 bridge by default provides short-id as a
container alias. With built-in SD feature, providing a container
short-id as a network alias will fill that gap.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
People have reported following problem.
- docker run -ti --name=foo -v /dev/:/dev/ fedora bash
- docker cp foo:/bin/bash /tmp
Once the cp operation is complete, it unmounted /dev/pts on the host. /dev/pts
is a submount of /dev/. This is completely unexpected. Following is the
reson for this behavior.
containerArchivePath() call mountVolumes() which goes through all the mounts
points of a container and mounts them in daemon mount namespace in
/var/lib/docker/devicemapper/mnt/<containerid>/rootfs dir. And once we have
extracted the data required, these are unmounted using UnmountVolumes().
Mounts are done using recursive bind (rbind). And these are unmounted using
lazy mount option on top level mount. (detachMounted()). That means if there
are submounts under top level mounts, these mount events will propagate and
they were "shared" mounts with host, it will unmount the submount on host
as well.
For example, try following.
- Prepare a parent and child mount point.
$ mkdir /root/foo
$ mount --bind /root/foo /root/foo
$ mount --make-rshared /root/foo
- Prepare a child mount
$ mkdir /root/foo/foo1
$ mount --bind /root/foo/foo1 /root/foo/foo1
- Bind mount foo at bar
$ mkdir /root/bar
$ mount --rbind /root/foo /root/bar
- Now lazy unmount /root/bar and it will unmount /root/foo/foo1 as well.
$ umount -l /root/bar
This is not unintended. We just wanted to unmount /root/bar and anything
underneath but did not have intentions of unmounting anything on source.
So far this was not a problem as docker daemon was running in a seprate
mount namespace where all propagation was "slave". That means any unmounts
in docker daemon namespace did not propagate to host namespace.
But now we are running docker daemon in host namespace so that it is possible
to mount some volumes "shared" with container. So that if container mounts
something it propagates to host namespace as well.
Given mountVolumes() seems to be doing only temporary mounts to read some
data, there does not seem to be a need to mount these shared/slave. Just
mount these private so that on unmount, nothing propagates and does not
have unintended consequences.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Following #19995 and #17409 this PR enables skipping userns re-mapping
when creating a container (or when executing a command). Thus, enabling
privileged containers running side by side with userns remapped
containers.
The feature is enabled by specifying ```--userns:host```, which will not
remapped the user if userns are applied. If this flag is not specified,
the existing behavior (which blocks specific privileged operation)
remains.
Signed-off-by: Liron Levin <liron@twistlock.com>
