ping @vishh @crosbymichael

LGTM 💯

With this, all container processes will in the same service or scope with daemon, so users can not control them by systemd commands, isn't that a regression we need to warn systemd users for now?

I agree we should allow to set parent systemd slice as I suggested in opencontainers/runc#336 (comment), but are we planning to achieve this with plain filesystem api and eventually remove systemd code for good? I think it'll be much easier to keep some systemd api and share others with cgroupfs. Anyway that's another story.

@hqhq Yeah, actually I plan to introduce daemon-wide cgroup in next release. Also I think all containers will be in PID 1 cgroup, not daemon cgroup.

@LK4D4 Agreed, we had proposal for daemon-wide cgroups long time ago, and create containers in root cgroup makes more sense, constraints like cpu.share will act more like they expected, also I think that'll simplify hierarchy and unify behavior between cgroupfs and systemd. 👍

what is a deamon-wide cgroup?

@crosbymichael like parent for all containers. There is nothing like this in this pr.

The parent is /docker/ right?

@crosbymichael I'm not sure, for me at least device cgroup in /user.slice/docker, but yes, for other cgroups it's docker.

@LK4D4 @crosbymichael I think daemon-wide cgroup is the cgroup for docker daemon, use it like docker daemon -m 2G, currently we create all container processes in daemon's cgroup with cgroupfs. It's not always in the same path because it depend on which cgroup daemon was in.

For example, daemon was in /sys/fs/cgroup/memory/, the root cgroup of memory, so container will in /sys/fs/cgroup/memory/docker/ae65xfe..., but if for devices cgroup, daemon was in /sys/fs/cgroup/devices/child/, container will in /sys/fs/cgroup/devices/child/docker/fdsafw76..., but the parent is always docker.

But the problem is systemd cgroup does not work like that, it always put container into system.slice by default, not into the daemon's cgroup, so that's not consistent. And I think always make containers have a parent docker doesn't make much sense, so I agree with what @LK4D4 will do.

How about providing a daemon flag which defines the default cgroup root for the daemon? It can default to /docker, but on systemd deployments, it can be overridden to /system.slice or some other slice?

@vishh that's what I had in mind

LGTM

@LK4D4: Can you update this PR to also include a daemon level flag for configuring the parent cgroup of all docker containers?

@vishh I prefer to do it in separate PR, because it'll be mostly docs PR and needed to be reviewed by more people.

Ok. I just want the configuration to land in the same release.

On Mon, Nov 16, 2015 at 10:44 AM, Alexander Morozov <
[email protected]> wrote:

@vishh https://github.com/vishh I prefer to do it in separate PR,
because it'll be mostly docs PR and needed to be reviewed by more people.

—
Reply to this email directly or view it on GitHub
#17704 (comment).

@vishh I'll create issue and add to milestone.

LGTM

I think this section needs updating.

@icecrime Yup, thanks!
ping @thaJeztah @moxiegirl for docs

@moxiegirl I changed your suggestion.

LGTM

Thank you @LK4D4 LGTM

@rhatdan it's not true for my systemd-226, because systemd doesn't put docker in docker.service at all. Could you show your docker.service? Is it in our repo?

How are you starting docker daemon? In the docker.service unit file?

Bottom line the container processes all end up being in the same scope as the docker daemon. This means if someone changes the cgroups of the docker daemon, all containers will be effected. If some one of the container processes registers with systemd-machine, and then terminates systemd will attempt to kill all processes in the same scope as the container, meaning all processes under the docker daemon. If you run the docker daemon by hand this means all container processes will be in the same scope as your user process.

@rhatdan Yes, I'm starting with systemd:

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
After=network.target docker.socket
Requires=docker.socket

[Service]
Type=notify
ExecStart=/usr/bin/docker daemon -H fd://
MountFlags=slave
LimitNOFILE=1048576
LimitNPROC=1048576
LimitCORE=infinity

[Install]
WantedBy=multi-user.target

What does systemd-cgls show? Where is the docker daemon running? Where is the container process running?

@rhatdan Sorry, seems like I misunderstood what we're talking here about. I thought we're talking about cgroups overall, but everything was about systemd cgroup. I'll fix this, no problem.

Right this is all about the "Scope" which in systemd terms is how it groups like processes together. Each user, service, vm gets its own "Scope". The problem with this change is the Docker container processes no longer get their own "Scope", they share the scope with the docker daemon.

@rhatdan Yeah, it appeared not so easy, because you can't just remove subscope from systemd cgroup :/

I see two sub-issues here:

1. Containers being grouped as cgroup children of docker daemon - This is undesirable. @LK4D4: I hope the daemon level flag you are planning on adding will land before this PR makes it into a release.
2. Starting docker container's under a *.scope cgroup - The main goal of this PR was to eliminate explicit systemd support in docker. Assuming that the motivation behind that change is valid, will it be possible to use the --cgroup-parent option to place docker containers under specific scopes @rhatdan? For example, unit files can include the following option --cgroup-parent=/system.slice/%H.scope.

Related issue: #18022

@vishh I will add flag tomorrow. However "name=systemd" cgroup seems to be usable only through systemd API. So, I'll appreciate any help on this. In worst case we will be forced to use systemd API even in fs cgroups(only for name=systemd).

I would hope --cgroup-parent would work. We plan on shipping the docker daemon with the systemd support turned on, since we don't agree with this patch, and feel that this is a breaking behaviour.

Does docker info report back the native.cgroupdriver that is configured?