From c2ba4a2864a8c5ef8b97d2484a46cbeb0b8fdf88 Mon Sep 17 00:00:00 2001 From: Daan De Meyer Date: Thu, 24 Apr 2025 22:53:01 +0200 Subject: [PATCH] docs: Document manual cgroup controller management for Delegate=yes This isn't immediately clear, so let's explicitly document this fact. More context in https://github.com/systemd/systemd/issues/7355. --- docs/CGROUP_DELEGATION.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/CGROUP_DELEGATION.md b/docs/CGROUP_DELEGATION.md index 076d560e65..2151bca921 100644 --- a/docs/CGROUP_DELEGATION.md +++ b/docs/CGROUP_DELEGATION.md @@ -254,6 +254,12 @@ 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.) +Finally, if you turn on cgroup delegation with `Delegate=yes`, systemd will make +the requested controllers available to your service or scope, but won't actually +enable them. Currently you have to do that manually by writing to +`cgroup.subtree_control` within your delegated cgroup (e.g. write `+memory` to +enable the memory controller). + ## Three Scenarios Let's say you write a container manager, and you wonder what to do regarding