People blow away `/var/lib/docker` all the time so we probably shouldn't
store important data there.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
(cherry picked from commit 9391057c9472ba24049b8645c251a4c63894522f)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 865140fc4155481b20f694a4528e04e48eb76de4
Component: packaging
Removes the need for the offline installer to install the shim process
and instead installs the shim process as part of the packaging.
May be easier in the future to just package the shim process on it's own
but that'll come after this 18.09 release
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
(cherry picked from commit f8bd366d58f8bdf8a82b9a033353ca5bf4eda948)
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 31d0cb047b98ab43f661bd026bdd63deef62543d
Component: packaging
Get's rid of architecture specific dockerfiles (yay manifest lists),
also follows very closely to what the RPM makefile does with the
sources.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: ab1ba336ad1720a166e8ed4469c616851d89a8d1
Component: packaging
This splits out the CLI into a discrete package and removes
the engine from the engine package. Instead the engine
is initialized via a post-inst script using the new CLI UX.
Upstream-commit: 662e248f680eb49a9951a8b34125506b8f82dfed
Component: packaging
Since systemd version 228, a new setting, `TasksMax`, has appeared,
which limits the number of tasks used by a service (via pids cgroup
controller). Unfortunately, a default for this setting, `DefaultTaskMax`,
is set to 512. In systemd version 231 it is changed to 15% which
practically is 4195, as the value from /proc/sys/kernel/pid_max is
treated like 100%).
Either 512 or 4195 is severily limited value for Docker Engine,
as it can run thousands of containers with thousands of tasks in each,
and the number of tasks limit should be set on a per-container basis
by the Docker user. So, the most reasonable setting for `TasksMax`
is `unlimited`.
Unfortunately, older versions of systemd warn about unknown `TasksMax`
parameter in `docker.service` file, and the warning is rather annoying,
therefore this setting is commented out by default, and is supposed
to be uncommented by the user.
The problem with that is, once the limit is hit, all sorts of bad things
happen and it's not really clear even to an advanced user that this
setting is the source of issues.
Now, `rules` file already contain a hack to check for the systemd
version (during build time) and in case the version is greater than 227,
uncomment the `TasksMax=unlimited` line. Alas, it does not work
during normal builds, the reason being systemd is not installed
into build environments.
An obvious fix would be to add systemd to the list of installed
packages in all Dockerfiles used to build debs. Fortunately,
there is a simpler way, as libsystemd-dev is installed, and
it's a subpackage of systemd built from the same source and
carrying the same version, so it can also be checked.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: d80738e4b4459816c64757a2a63e5d8058d0ccf4
Component: packaging
Tried out make -C in this scenario and it did not seem to function
correctly, changed to cd.
Signed-off-by: Eli Uriegas <eli.uriegas@docker.com>
Upstream-commit: 3a548f8815d5308b197abea1e39f0a0a4939c4f2
Component: packaging
Add armhf dockerfiles for deb building
Signed-off-by: Eli Uriegas <seemethere101@gmail.com>
Upstream-commit: f0c8cea1b79b049743cd1503f7ac4a34c265f476
Component: packaging
