I have opened a Change Request to change the defaults for Fedora 31 to
Cgroups V2.  I am looking for what packages will be affected by this
change.   Basically any package that adjusts Cgroups via the CgroupFS,
my understanding is working the the systemd APIs, you should be fine.

Packages That I know will be affected:

Container Tools

* Runc, Podman, Buildah, Kubernetes, Docker, Moby-engine

Virtualization tools

* Libvirt


* jvm


* Anaconda

Anyone know of other packages?



By Daniel P. Berrange at 02/14/2019 - 11:49

On Thu, Feb 14, 2019 at 08:10:09AM -0500, Daniel Walsh wrote:
What is the expectation of compatibility for applications running inside
containers ?

Historically any running containers will see a v1 hierarchy inside their
container. If the host is switched to v2, then presumably applications
inside the container will also see a v2 layout.

The wiki page says tools/scripts would be unaffected if they had used
the systemd interface to access cgroups. This won't apply to tools
or scripts inside the container though as the containers rarely run
systemd inside.

If this is correct, then even if all software in Fedora supports v2,
users might still see breakage of applications they are running in
containers on Fedora.

Admittedly the set of things likely to be affected in this way is probably
fairly small, but it feels like something that should be described in
the change page on the wiki.



By Daniel J Walsh at 02/14/2019 - 15:00

On 2/14/19 10:49 AM, Daniel P. Berrangé wrote:
I will update the Change with a comment on this.


By Zbigniew =?utf-... at 02/14/2019 - 11:30

On Thu, Feb 14, 2019 at 08:10:09AM -0500, Daniel Walsh wrote:
Great news!

Can you briefly summarize the status / plans / timelines for the
affected components?
(Apart from anaconda, which doesn't need changes, we'll just flip the
default in systemd, as discussed in the other subthread.)



By King InuYasha at 02/15/2019 - 07:51

On Fri, Feb 15, 2019 at 4:11 AM Zbigniew Jędrzejewski-Szmek
< ... at in dot> wrote:
snapd will break in cgroupv2 mode:
<a href="" title=""></a>

I don't know of anyone working on fixing that...


By Zygmunt Krynicki at 02/15/2019 - 07:55

I think the stance of the snapd team is that once v2 supports freezer we can have a look at adding the support.

There’s a snapd bug tracking this as well: <a href="" title=""></a> <>

I’m happy to work on this issue once it becomes „pressing” and once the prerequisites are available. If F30 disables v1 entirely and has a kernel where we can get device, freezer and pid controllers then it’s „just” a matter of coding.

Best regards


By Daniel J Walsh at 02/15/2019 - 09:08

On 2/15/19 6:55 AM, Zygmunt Krynicki wrote:
This is for F31 NOT f30.  Also you will be able to boot the machine in
V1 mode. We are just talking about the default here.


By Lennart Poettering at 02/15/2019 - 08:02

The kernel will support both modes for a long time I figure. And so
will systemd. You can switch between both modes at boot time through a
kernel cmdline option, and the change for F30 would be to just default
to a different setting.

Note that in cgroupsv2 mode systemd will not mount the cgroupv1
hierchies at all. (You can mount them yourself if you want to
though. For example, systemd-nspawn can optionally provide cgroupsv1
to container payloads on cgroupsv2 hosts, by simply mounting the
name=systemd hierarchy into the container anyway)

The "devices" cgroup controller is generally not available on
cgroupsv2. However, there's now a set of bpf hook-ups that you can use
instead and provide pretty much equivalent functionality. (systemd
supports them already).

The "freezer" cgroup controller is not available yet on cgroupsv2. But
this is likely going to change soon, but it will be core cgroupsv2
functionality, not a controller of its own. Until the freezer becomes
available it should be completely fine to simply use SIGSTOP instead,
semantics are not thaaaaat different.

The "pids" controllers has been available on cgroupsv2 since day one
basically, at the same day it was introduced for cgroupsv1.



By Daniel J Walsh at 02/15/2019 - 09:11

On 2/15/19 7:02 AM, Lennart Poettering wrote:


By Zygmunt Krynicki at 02/15/2019 - 08:42

Indeed, the is a possible way out. It requires some thought on our side to integrate with our current use of v1 devices cgroup, udev rules, snapd side „hot plug” and live changes to running programs (which v1 devices allowed).

We use the freezer for „snap scope” process enumeration (but there are other ways to do that) and to crucially, stop processes while we perform some mount namespace updates, so that there’s less risk of apps attacking the mount code with racing symlinks and what not. Using SIGSTOP for that is, I guess, okay, as long as we can „win” and stop all processes in a given snap reliably enough.

Yeah. I’m trying to move some of the burden from the freezer to pid so that snapd doesn’t rely on the freezer that much.


By Lennart Poettering at 02/15/2019 - 08:58

The bpf devices thing allows live changes too. In fact, in the bpf logic in
systemd it's implemented that way already.

Well, the SIGSTOP thing is racy: processes can fork() quicker than you
can pause them. Together with the pids controller you should be fine
though, as you can put a limit on forks.



By =?UTF-8?Q?Ji=C5... at 02/14/2019 - 10:55

Hi Dan,

How the Anaconda will be affected? I'm not aware of any cgroups control
from Anaconda side or do we need change something to the installed
system to enable v2 cgroups?

Thanks for answers,

On Thu, 2019-02-14 at 08:10 -0500, Daniel Walsh wrote:


By Daniel J Walsh at 02/14/2019 - 14:58

On 2/14/19 9:55 AM, <a href="mailto: ... at redhat dot com"> ... at redhat dot com</a> wrote:


By Daniel J Walsh at 02/14/2019 - 14:59

Ok I guess this will not effect anaconda, just affect systemd.

On 2/14/19 1:58 PM, Daniel Walsh wrote:


By =?UTF-8?Q?Ji=C5... at 02/15/2019 - 04:40

OK, thanks Dan and Lennart for explanation.

I also think it would be better to make this happen in the systemd RPM.
It feel more suitable place for these kind of settings.


On Thu, 2019-02-14 at 13:59 -0500, Daniel Walsh wrote:


By Lennart Poettering at 02/14/2019 - 11:11

The feature page suggests the installer would switch from cgroupsv1 to

My suggestion would instead be to simply update the systemd RPM to
pass slightly different params to meson, to make cgroupsv2 the new