Add cgroup v2 support

[ss1h2a3tw]

Hi, currently runguard is using libcgroup to manipulate cgroup creation and controller settings. But some distributions are moving to cgroup v2:
Fedora https://www.redhat.com/sysadmin/fedora-31-control-group-v2
RHEL https://www.redhat.com/ja/blog/world-domination-cgroups-rhel-8-welcome-cgroups-v2
Archlinux https://wiki.archlinux.org/index.php/cgroups#Enable_cgroup_v1

It will be nice if we have cgroup v2 support at future. libcgroup seems not to be supporting cgroupv2 in their C API, but since the file structure is unified, it shouldn't be too complex to just creating directories in cgroup's VFS.

[nickygerritsen]

Note that Docker for Mac recently switched to cgroup v2 as well.

[rfleischer]

Hi, my sysadmin refuses to install DOMJudge if it does not support cgroup v2. Are there any plans to upgrade DOMJudge?

[nickygerritsen]

We have looked into this already but it is super non trivial. The API changed and some stuff is hard / not doable, so we need to investigate. I don't think it's on a timeline anytime soon.

[meisterT]

Unfortunately, it looks like we currently have to wait until libcgroup-dev becomes available in debian stable in version v3.0+. I very much would hope that this is next summer, but I am skeptical as the version is only in experimental right now.

[meisterT]

I was mistaken, cgroup v2 support is partially available libcgroup v2.0.

[RaitoBezarius]

systemd v255 (currently in rc3 or something) will officially remove cgroup v1 AFAIK, so from now on, DomJudge won't run anymore on up-to-date systems.

[holmes111]

Hi, I wanted to ask if it is soon planned to support cgroups v2, as the deprecation of cgroups v1 is coming closer...

[vmcj]

Hi, I wanted to ask if it is soon planned to support cgroups v2, as the deprecation of cgroups v1 is coming closer...

The coming months we are not planning to implement larger/harder features. As far as I'm aware (but didn't do extensive research on the subject) we can still use cgroupv1 as it is still supported with the kernel but only systemd will not support it anymore. Do you have more information on the subject? The main issue is that not all needed features are implemented in CGroupV2 so we can't do a 1 to 1 translation.

According to the kernel (https://github.com/torvalds/linux/blob/b401b621758e46812da61fa58a67c3fd8d91de0d/tools/testing/selftests/bpf/cgroup_helpers.h#L32) cgroupv1 is still tested for.

[meisterT]

Pull requests adding cgroupv2 functionality are of course welcome!

[Johnnynator]

I have a WiP port of runguard to cgroupv2 https://github.com/Johnnynator/domjudge/tree/cgroup
with some assumptions that are not correct for domjudge (would need minor adjustments since the port is configured to create a systemd slice and scope with different naming than the old group) (Tested in a setup with jobe)

The main issue is that not all needed features are implemented in CGroupV2 so we can't do a 1 to 1 translation.

The only major difference I noticed was that memory is now hard split between memory and swap and no combined limit_in_bytes
I did not notice any other major differences

I was mistaken, cgroup v2 support is partially available libcgroup v2.0.

Anything before v3.1 has bugs that would need workarounds in the code.

[nickygerritsen]

Thanks for this! We will look into your code to see what we can reuse (and of course credit you if we do).

[HeRaNO]

systemd/systemd#31442 will be included in systemd v256. Maybe we should ramp up cgroups v2 support...

[Kevinjil]

I think we should wait for #2344 before implementing this.

[meisterT]

I was mistaken, cgroup v2 support is partially available libcgroup v2.0.

Anything before v3.1 has bugs that would need workarounds in the code.

Do you know what these bugs / required workarounds are?

It looks like both Ubuntu 24.04 and debian testing have libcgroup-dev 2.0.2 :-/

[Johnnynator]

Do you know what these bugs / required workarounds are?

One was missing integration with systemd slices/scopes ( cgroup delegation ).
With systemd v254 one could just use DelegateSubgroup= and some static always running service to work around this and not needing any additional code.

There were also a few functions that did still expect v1 internally, and if my memory server me correct, it was something in the core part of the library that couldn't be worked around externally (I can check next week if I have some notes about this on my $work machine).
I did not bother that much getting 2.0.2/2.0.3 working since it is explicitly deprecated by upstream and since 3.0.1 did have everything properly fixed.

Linking against a newer statically compiled libcgroup is probably the easiest option.

[mpsijm]

Recently upgraded my Arch, which includes systemd v256. My boot sequence now takes 30 seconds longer than usual, thanks to https://github.com/systemd/systemd/pull/31442/files#diff-03b3e8b6554bb8ccd539ad2e547d9ef13f80428101bdc01b4d6e9ea5f685fe7cR3032-R3033 😅

log_full(LOG_CRIT, "Legacy cgroup v1 support selected. This is no longer supported. Will proceed anyway after 30s.");
(void) usleep_safe(30 * USEC_PER_SEC);

Linking against a newer statically compiled libcgroup is probably the easiest option.

Does this work if the base system does not run the latest systemd? For reference, Ubuntu 22.04 (jammy) runs v249, Ubuntu 24.04 (noble) runs v255, Debian 11 (bullseye) runs v247, Debian 12 (bookworm) runs v252

[meisterT]

lol, what an interesting strategy to annoy users

Anyway, I have cgroups v2 working locally and on github actions, but I need to clean up the code. I will do that soon and send a PR.

[RagnarGrootKoerkamp]

I also ran into this now, but because of less frequent updates for me it didn't hang for 30s, but just refused to boot. (Yes, hanging is a good way to warn users after all.)

For me, the fix was to remove the systemd.unified_cgroup_hierarchy=0 kernel, or rather, to completely remove the boot entry with that parameter set. (And accept that domjudge won't work for now.)

Looking into this, the swapaccount=1 flag mentioned in the docs seems deprecated.

[mpsijm]

Fixed in #2588? 😄

[nickygerritsen]

Indeed 🎉