plugin.
The merge is inert, in other words the devmapper code is not called
and the primary aufs backend is untouched.
Upstream-commit: 36c7a7ae943220ffb1bea9cd47d2f586db00eab2
Component: engine
Remove docker link
Do not add container id as default name
Create an auto generated container name if not
specified at runtime.
Upstream-commit: 0d2924408bad7aa797bfaf0610e836d82928296f
Component: engine
This will be needed for later use in docker-init without a docker
dependency
Upstream-commit: d063c8d941d366e4815b91c4fa4fc91fc1e1eb23
Component: engine
Column 4 is the mount position, column 3 will not always be
"/" for the root. On one of my system its "/root".
Upstream-commit: d263aa6ca916ba9141f341447a2387e7a6316717
Component: engine
This happened for me on the last (empty) line, but better safe than sorry
so we make the check general.
Upstream-commit: d478a4bb5401d7d657a2a100f98ee892a96fef2a
Component: engine
lxc-start requires / to be mounted private, otherwise the changes
it does inside the container (both mounts and unmounts) will propagate
out to the host.
We work around this by starting up lxc-start in its own namespace where
we set / to rprivate.
Unfortunately go can't really execute any code between clone and exec,
so we can't do this in a nice way. Instead we have a horrible hack that
use the unshare command, the shell and the mount command...
Upstream-commit: e40f5c7cb90fbc719241ace45b05c2c61aced658
Component: engine
For consistency the Buildfile should have the option to
set the working directory.
Of course that is one option more to the buildfile,
so please tell me if we really want this to happen.
Upstream-commit: 319988336ceed4428de0e1e55685f8a0ed48a7bd
Component: engine
By setting an entrypoint in the Dockerfile this
allows one to run an image and only pass arguments.
Upstream-commit: b16ff9f8598d30823f687d100d351cad11823e77
Component: engine
Fall back to image-specified hostname if user doesn't
provide one, instead of only using image-specified
hostname if the user *does* try to set one.
(ditto for username)
Closes#694.
Upstream-commit: 83bc5b7435565d227a7745f4832bc9ce6be7a80d
Component: engine
Specifically, Ubuntu Precise's cgroup-lite script uses mount -n
to mount the cgroup filesystems so they don't appear in mtab, so
detection always fails unless the admin updates mtab with /proc/mounts.
/proc/mounts is valid on just about every Linux machine in existence and
as a bonus is much easier to parse.
I also removed the regex in favor of a more accurate parser that should
also support monolitic cgroup mounts (e.g. mount -t cgroup none /cgroup).
Upstream-commit: c6119da33925fccf6af3f232f7aa7c75de41493b
Component: engine
On Gentoo, the memory cgroup is mounted at /sys/fs/cgroup/memory, but the mount line looks like the following:
memory on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
(note that the first word on the line is "memory", not "cgroup", but the other essentials are there, namely the type of cgroup and the memory mount option)
Upstream-commit: e413340723871ad2d7a03822ca06993ee3c0a4bc
Component: engine