1
0
mirror of https://github.com/systemd/systemd.git synced 2024-12-22 17:35:35 +03:00

docs: make clear that if you use threaded cgroups you need to do that two levels down from your delegated cgroup

Prompted by: #22486
This commit is contained in:
Lennart Poettering 2022-02-14 18:05:31 +01:00 committed by Luca Boccassi
parent d74da762a3
commit 1d7150ec7f

View File

@ -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 that the service's main cgroup is definitely an inner node by the time the
service manager might start `ExecStartPost=`.) 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 ## Three Scenarios
Let's say you write a container manager, and you wonder what to do regarding Let's say you write a container manager, and you wonder what to do regarding