Kir Kolyshkin
1c517bd52c
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.
As Fedora 25 ships systemd 231, it (and later Fedora releases) support
TasksMax, so it makes total sense to uncomment the setting, this is what
this commit does.
[17.12: added patch for Fedora 25 spec]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Upstream-commit: 9055832bb0725f05d518c3ebc9b7cc93a69420c7
Component: packaging
(cherry picked from commit 02b6af2e96)
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Docker CE
This repository hosts open source components of Docker CE products. The
master branch serves to unify the upstream components on a regular
basis. Long-lived release branches host the code that goes into a product
version for the lifetime of the product.
This repository is solely maintained by Docker, Inc.
Issues
There are separate issue-tracking repos for the end user Docker CE products specialized for a platform. Find your issue or file a new issue for the platform you are using:
- https://github.com/docker/for-linux
- https://github.com/docker/for-mac
- https://github.com/docker/for-win
- https://github.com/docker/for-aws
- https://github.com/docker/for-azure
Unifying upstream sources
The master branch is a combination of components adapted from
different upstream git repos into a unified directory structure using the
moby-components
tool.
You can view the upstream git repos in the components.conf file. Each component is isolated into its own directory under the components directory.
The tool will import each component git history within the appropriate path.
For example, this shows a commit
is imported into the component engine from
moby/moby@a27b4b8
into the components/engine directory.
commit 5c70746915d4589a692cbe50a43cf619ed0b7152
Author: Andrea Luzzardi <aluzzardi@gmail.com>
Date: Sat Jan 19 00:13:39 2013
Initial commit
Upstream-commit: a27b4b8cb8e838d03a99b6d2b30f76bdaf2f9e5d
Component: engine
components/engine/container.go | 203 ++++++++++++++++++++++++++++...
components/engine/container_test.go | 186 ++++++++++++++++++++++++++++...
components/engine/docker.go | 112 ++++++++++++++++++++++++++++...
components/engine/docker_test.go | 175 ++++++++++++++++++++++++++++...
components/engine/filesystem.go | 52 ++++++++++++++++++++++++++++...
components/engine/filesystem_test.go | 35 +++++++++++++++++++++++++++
components/engine/lxc_template.go | 94 ++++++++++++++++++++++++++++...
components/engine/state.go | 48 ++++++++++++++++++++++++++++...
components/engine/utils.go | 115 ++++++++++++++++++++++++++++...
components/engine/utils_test.go | 126 ++++++++++++++++++++++++++++...
10 files changed, 1146 insertions(+)
Updates to master branch
Main development of new features should be directed towards the upstream
git repos. The master branch of this repo will periodically pull in new
changes from upstream to provide a point for integration.
Branching for release
When a release is started for Docker CE, a new branch will be created
from master. Branch names will be YY.MM to represent the time-based
release version of the product, e.g. 17.06.
Adding fixes to release branch
Note: every commit of a fix should affect files only within one component directory.
Fix available upstream
A PR cherry-picking the necessary commits should be created against the release branch. If the the cherry-pick cannot be applied cleanly, the logic of the fix should be ported manually.
No fix yet
First create the PR with the fix for the release branch. Once the fix has been merged, be sure to port the fix to the respective upstream git repo.
Release tags
There will be a git tag for each release candidate (RC) and general availablilty (GA) release. The tag will only point to commits on release branches.