From: Lennart Poettering Date: Mon, 14 Feb 2022 17:05:31 +0000 (+0100) Subject: docs: make clear that if you use threaded cgroups you need to do that two levels... X-Git-Tag: v251-rc1~296 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=1d7150ec7fd819805b2a19b1dd485be7de54a6a8;p=thirdparty%2Fsystemd.git docs: make clear that if you use threaded cgroups you need to do that two levels down from your delegated cgroup Prompted by: #22486 --- diff --git a/docs/CGROUP_DELEGATION.md b/docs/CGROUP_DELEGATION.md index 03340e7e8f7..926d16eef6e 100644 --- a/docs/CGROUP_DELEGATION.md +++ b/docs/CGROUP_DELEGATION.md @@ -266,6 +266,15 @@ tree by the time it notifies the service manager about start-up readiness, so that the service's main cgroup is definitely an inner node by the time the service manager might start `ExecStartPost=`.) +(Also note, if you intend to use "threaded" cgroups — as added in Linux 4.14 —, +then you should do that *two* levels down from the main service cgroup your +turned delegation on for. Why that? You need one level so that systemd can +properly create the `.control` subgroup, as described above. But that one +cannot be threaded, since that would mean `.control` has to be threaded too — +this is a requirement of threaded cgroups: either a cgroup and all its siblings +are threaded or none –, but systemd expects it to be a regular cgroup. Thus you +have to nest a second cgroup beneath it which then can be threaded.) + ## Three Scenarios Let's say you write a container manager, and you wonder what to do regarding