cgroupv2: fix fs2 driver default path

[kolyshkin]

When the cgroupv2 fs driver is used without setting cgroupsPath,
it picks up a path from /proc/self/cgroup. On a host with systemd,
such a path can look like (examples from my machines):

• /user.slice/user-1000.slice/session-4.scope
• /user.slice/user-1000.slice/user@1000.service/gnome-launched-xfce4-terminal.desktop-4260.scope
• /user.slice/user-1000.slice/user@1000.service/gnome-terminal-server.service

This cgroup already contains processes in it, which prevents to enable
controllers for a sub-cgroup (writing to cgroup.subtree_control fails
with EBUSY or EOPNOTSUPP).

Obviously, a parent cgroup (which does not contain tasks) should be used.

Fixes: #2298

[kolyshkin]

@AkihiroSuda PTAL. You might want a similar change in containers/cgroups's NestedGroupPath(), although I'm not sure if it has any users (yet?).

This patch can be amended by checking first if a cgroup has any users, and if so, moving up, but I don't think it's necessary.

[mrunalp]

LGTM

[kolyshkin]

So, @brauner says that if a host is running systemd, we must use systemd:
#1708 (comment)
and he also describes the approach of "going one level up" (item 2 item 3) which is used here.

Edited: fix item number

[AkihiroSuda]

LGTM

[h-vetinari]

@kolyshkin: and he also describes the approach of "going one level up" (item 2) which is used here.

Ummmm... (not sure if "describes" is the right word, plus "one level up" is his Oprion 3?):

@brauner:

1. [...]
2. you escape to the root cgroup
3. you escape one level up form the cgroup the processes are located in
4. [...]

[...] Option 2 is a big nono as the root cgroup is owned by systemd and is free to do whatever it wants with your processes. You're also violating the single writer rule. Option 3 is another big nono for all the reasons 2 is. [...]

[brauner]

So, @brauner says that if a host is running systemd, we must use systemd:
#1708 (comment)
and he also describes the approach of "going one level up" (item 2) which is used here.

Hey Kir,

You don't necessarily need to run systemd in the container. I might've not expressed myself well enough. The generic problem is that on a v2-only host you can't run an init process in the container that does cgroup management and which is v1 or hybrid mode aware only. This is e.g. is the case for old systemds as systemd will simply freeze if it can't mount named=systemd which it uses for process tracking if the cgroup2 hierarchy is not available. Though nowadays on most supported distros systemd can be told to use the unified hierarchy only.

[kolyshkin]

Though nowadays on most supported distros systemd can be told to use the unified hierarchy only.

Yes, I am targeting the v2-only unified hierarchy in mind, as this is the way it's going to be (and it already is in F31 by default).

[kolyshkin]

With checkpoint/restore tests disabled for v2 but no systemd, CI passes.