cc @tmds

Nice work @omajid !

I don't intend to look into this/try it until I have a fedora 32 install. I think this is important, but not urgent.

@tmds Just for the record, Fedora 31 (released today, I think) has cgroupv2 enabled by default. Everything not supporting cgroupv2 (eg, docker/moby) is broken. This seems somewhat urgent to me.

What is the effect for a .NET Core app that only supports cgroupv1?
Did cgroupv2 remove the files that were used by v1, or is there some backwards compatibility?

What is the effect for a .NET Core app that only supports cgroupv1?

It wont be able to run on a kernel using cgroup2 (eg, Fedora 31, or even Fedora 30 with modified kernel boot parameters).

Did cgroupv2 remove the files that were used by v1, or is there some backwards compatibility?

There's been some re-organziation of things on the kernel side. The cgroup hierarchy is a bit different between the two cgroup versions. As are the names and contents of files that contain data. There's no backward or forward compatibility: an application that only handles cgroup v1 locations and data will not work with cgroup v2 (and the other way around).

However, it's pretty easy to support both cgroup versions. We can detect the cgroup version at runtime and read the appropriate configuration/files.

It wont be able to run on a kernel using cgroup2

Ah. I may be misremembering.. I thought not being able to parse cgroup info was not a fatal error.

an application that only handles cgroup v1 locations and data will not work with cgroup v2 (and the other way around).

I see. The kernel doesn't often break backwards compatibility.
I had noticed in your PR that the names don't overlap, so I thought both might still be available.

Ah. I may be misremembering.. I thought not being able to parse cgroup info was not a fatal error.

My bad. You are correct: it's not a fatal error. .NET Core just wont realize it's running under cgroup restrictions.

3.0 has been EOL for ages