Delegated unit: unable to enable memory controller in cgroup.subtree_control

[darkyzhou]

Component

systemd

Is your feature request related to a problem? Please describe

According to the documentation:

Generally, the Delegate property is only useful for services that need to manage their own cgroup subtrees, such as container managers. After creating a unit with this property set, they should use /proc/$PID/cgroup to figure out the cgroup subtree path they may manage (the one from the name=systemd hierarchy!). Managers should refrain from making any changes to the cgroup tree outside of the subtrees for units they created with the Delegate flag turned on.

I was creating a transient scope like this:

var properties []systemdDbus.Property

properties = append(properties, systemdDbus.PropSlice("user.slice"))
properties = append(properties, newProp("Delegate", true))
properties = append(properties, newProp("DefaultDependencies", false))

// This will move the current process into the cgroup created by the scope
properties = append(properties, systemdDbus.PropPids(uint32(os.Getpid())))

_ = startUnit(dbus, "foo.scope", properties);

And expecting to manage the memory in the subtrees by writing +memory into cgroup.subtree_control, but got the error: device or resource busy.

After checking the cgroup manpage, I found that this is probably related to a rule called "no internal processes":

The "no internal processes" rule is in fact more subtle than
stated above.  More precisely, the rule is that a (nonroot)
cgroup can't both (1) have member processes, and (2) distribute
resources into child cgroups—that is, have a nonempty
cgroup.subtree_control file.  Thus, it is possible for a cgroup
to have both member processes and child cgroups, but before
controllers can be enabled for that cgroup, the member processes
must be moved out of the cgroup (e.g., perhaps into the child
cgroups).

With the Linux 4.14 addition of "thread mode" (described below),
the "no internal processes" rule has been relaxed in some cases.

AFAICT, what it means is that the controllers I could enable only includes those that supports "thread mode", which doesn't include the memory controller. Is this as expected?

If so, how can I control the memory in the subtrees of a scope? Did I missed something?

If not, is it a good idea for systemd to provide a new option to setup cgroup.subtree_control BEFORE writing the pid into cgroup.procs?

I tried moving the process from the scope's cgroup into a child of it, and was able to enable the memory controller in the scope's cgroup. But this way I broke the systemd's rule:

Managers should refrain from making any changes to the cgroup tree outside of the subtrees for units they created with the Delegate flag turned on.

Any help will be appreciated!

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

The systemd version you checked that didn't have the feature you are asking for

252.2-2-arch

[darkyzhou]

I checked https://systemd.io/CGROUP_DELEGATION/ again:

The i-like-islands option. ... Don’t forget the no-processes-in-inner-nodes rule however: you have to move your main daemon process out of that cgroup (and into a sub-cgroup) before you can start further processes in any of your sub-cgroups.

So maybe moving the main process into a sub-cgroup is acceptable for systemd?

[poettering]

If you have a delegated cgroup then you are supposed to manage it yourself, i.e. create a subgroup, move yourself there, and so on. it's what delegation means: you want your own subtree, hence manage it, and do so adhering to the various rules such as "no processes in inner nodes".