Cgroup2 support/migration

[hammerandtongs]

In looking to use https://github.com/facebookincubator/oomd/ to solve the memory pressure issues that occur on linux desktops https://lkml.org/lkml/2019/8/4/15 (note that turning off swap is not necessary to trigger this pathology) it comes that oomd is designed with cgroup2 in mind.

from man cgroups

Although cgroups v2 is intended as a replacement for cgroups v1, the older system continues to exist (and for compatibil‐ ity reasons is unlikely to be removed). Currently, cgroups v2 implements only a subset of the controllers available in cgroups v1. The two systems are implemented so that both v1 controllers and v2 controllers can be mounted on the same system. Thus, for example, it is possible to use those controllers that are supported under version 2, while also using version 1 controllers where version 2 does not yet support those controllers. The only restriction here is that a con‐ troller can't be simultaneously employed in both a cgroups v1 hierarchy and in the cgroups v2 hierarchy.

What are the implications for the current implementation of firejail?

Can it run successfully with a cgroup2 memory controller?

What would need to be done to the codebase to migrate to cgroup2 in an orderly way?

[netblue30]

We will have to redo all the cgroups support, thanks.

[hammerandtongs]

Fedora 31 has a plan to migrate to cgroupsv2

https://fedoraproject.org/wiki/Changes/CGroupsV2

The tracking bug is -

https://bugzilla.redhat.com/show_bug.cgi?id=1732114

I'm not a Fedora user but it seems like they should know this would cause Firejail problems.

I didn't find any activity in the Ubuntu launchpad around cgroupsv2

Also Systemd 243 RC2 ""The unified cgroup hierarchy (cgroupsv2) is now the default. Use systemd.unified-cgroup-hierarchy=0 on the kernel command line to undo this change."""

None of this keeps me from using firejail, it's just more fwiw (I'm going to explore a "pkill chromium" to the pressure stall kernel bits to solve my oom issues ).

[martinetd]

For whoever stumbles upon this and would like to add a cgroup for e.g. memory limitation, the easiest probably is to just leave the cgroup management to systemd and have firejail inherit it e.g. something like this:

$ systemd-run --user --scope --unit=firefox-$$.scope \
        -p MemoryMax=3G -p MemoryHigh=2G \
        firejail firefox

(--scope makes the command behave like a normal process, e.g. it inherits the env and exits when the child command exits)

which has the bonus that you can query its usage through systemctl status:

$ systemctl --user status firefox*.scope
● firefox-2960246.scope - /usr/bin/firejail firefox
     Loaded: loaded (/run/user/1000/systemd/transient/firefox-2960246.scope; transient)
  Transient: yes
     Active: active (running) since Tue 2021-11-30 22:33:02 JST; 2min 28s ago
      Tasks: 229 (limit: 18792)
     Memory: 668.3M (high: 2.0G max: 3.0G)
        CPU: 1min 47.597s
     CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/firefox-2960246.scope
             ├─2960246 /usr/bin/firejail firefox
             ├─2960247 /usr/bin/xdg-dbus-proxy --fd=9 --args=10
             ├─2960249 /usr/bin/firejail firefox
             ├─2960258 /usr/lib64/firefox/firefox
             ├─2960532 /usr/lib64/firefox/firefox -contentproc -parentBuildID 20211101135957 -prefsLen>
             ├─2960557 /usr/lib64/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 65 ->
             ├─2960630 /usr/lib64/firefox/firefox -contentproc -childID 3 -isForBrowser -prefsLen 467 >
             ├─2960669 /usr/lib64/firefox/firefox -contentproc -childID 4 -isForBrowser -prefsLen 4998>
             └─2960741 /usr/lib64/firefox/firefox -contentproc -childID 5 -isForBrowser -prefsLen 5689>

Nov 30 22:33:02 myhostname systemd[1694]: Started /usr/bin/firejail firefox.