How can I enable cgroup controllers while running podman in gnome terminal?

[xjvs]

Hi podman community,

I have a question regarding running podman with all cgroup controllers enabled while podman is running in gnome terminal, by default I only see "memory pids" controllers are enabled.

$ cat /etc/systemd/system/[email protected]/delegate.conf 
[Service]
Delegate=yes

$ cat /sys/fs/cgroup/user.slice/user-1000.slice/cgroup.controllers 
cpuset cpu io memory pids

$ podman info --format '{{json .}}' | jq .host.cgroupControllers
[
  "memory",
  "pids"
]

By checking the code, I see podman read the controllers from /sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-a625836f-4175-40b5-90c8-30aa31f59449.scope/cgroup.controllers,

(dlv) call getCgroupPathForCurrentProcess()
> github.com/containers/common/pkg/cgroups.getAvailableControllers() /path/to/containers/podman/vendor/github.com/containers/common/pkg/cgroups/cgroups.go:144 (PC: 0xf3f9c8)
Values returned:
	~r0: "/user.slice/user-1000.slice/[email protected]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-a625836f-4175-40b5-90c8-30aa31f59449.scope"
	~r1: error nil

(dlv) p controllersFile
"/sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-a625836f-4175-40b5-90c8-30aa31f59449.scope/cgroup.controllers"

Seems each gnome-terminal tab has a separate systemd scope and cpuset cpu io controllers are not enabled by default.

$ cat /sys/fs/cgroup/user.slice/user-1000.slice/[email protected]/app.slice/app-org.gnome.Terminal.slice/vte-spawn-a625836f-4175-40b5-90c8-30aa31f59449.scope/cgroup.controllers
memory pids

How can I enabled the missing controllers in gnome terminals by default?

Additional info:
OS: Fedora release 35 x86_64
kernel: kernel-5.16.14-200.fc35.x86_64
gnome: gnome-41, gnome-terminal-3.42.2-1.fc35.x86_64
podman: podman-4.0.2-5.fc35.x86_64

[rhatdan]

@giuseppe PTAL

[giuseppe]

you need to create a file under /etc/systemd/system/[email protected] that contains something like:

[Service]
Delegate=cpu cpuacct io memory pids

so these controllers will be delegated to the unprivileged user and can be used for containers

[xjvs]

Have you restarted the user session?

Yes, I also tried rebooting the system, as described in my question, I guess the reason is gnome-terminal tab has a separate systemd scope and cpuset cpu io controllers are not enabled by default, and podman gets the controllers from gnome terminal vte slice.

The reason why I'm asking this is I want to start a kind cluster with rootless podman (https://kind.sigs.k8s.io/docs/user/rootless/), but kind requires podman to have cpu controller enabled, I wondering how I can change the default behavior of gnome-terminal to have all (or at least cpu memory pids) controllers enabled.

[giuseppe]

you can try to run in a new systemd scope:

systemd-run -p Delegate=yes --user --scope podman ...

[xjvs]

you can try to run in a new systemd scope:

systemd-run -p Delegate=yes --user --scope podman ...

Thank you, this can be a workaround if I create a podman script with systemd-run -p Delegate=yes --user --scope podman "$@" and put it before the original podman in $PATH, but seems we don't have a better solution to change the default enabled cgroup controllers for gnome-terminal tabs.

[akosiaris]

Just found this issue, thanks for all the information. Kinda old but adding 1 more way this can be solved. We can override the vte-spawn scope and add our own entries per VTE docs. So:

$ cat $HOME/.config/systemd/user/vte-spawn-.scope.d/delegate.conf 
[Scope]
Delegate=yes

and systemctl --user daemon-reload, stop all terminals, start a new one, verify

$ systemctl --user show -p Delegate vte-spawn-cc1d2684-231b-4257-970a-b560cd8e9a48.scope 
Delegate=yes

Note that this solution is not specific to podman but applies to anything started from a VTE terminal. Furthermore, it is less restrictive than the default as it transfers control of cgroup resource control partitioning from the systemd user instance to VTE. I don't offhand know of a use case in a default installation where this would introduce a vulnerability, but I might very well be wrong. systemd docs say the following:

Note that controller delegation to less privileged code is only safe on the unified control group hierarchy. Accordingly, access to the specified controllers will not be granted to unprivileged services on the legacy hierarchy, even when requested.

so, the choice of cgroup hierarchy is irrelevant.

Let me know if this is a bad idea.