纯统一cgroup v2容器环境下出现假阳性警告： In multiple cgroups, cannot determine cgroup root path

This message is a warning, not an error. I don't think there's any Dinit bug here?

在未强制v1情况下，是纯 cgroup v2。并没有真正挂载 cgroup v1 控制器，但 /proc/self/cgroup 里仍然有 Android 内核残留的 v1 条目，从而触发了这个警告。Dinit 运行正常，这只是一个误报警告。

一个可行思路：检测 cgroup v1 是否真正可用。如果 v1 不可用，则直接使用 cgroup v2；仅当 v1 确实可用时，才输出这条警告。

主机内核同时开启v1+v2的混合模式下，即便容器内部只能使用v2， /proc/self/cgroup  依然会出现v1的条目，造成误判。 我猜这也是这条警告的初衷：当v1和v2同时可用时提醒冲突风险。但仅依靠  /proc/self/cgroup  判断，无法区分「层级存在」和「当前环境v1是否可用」，在混合内核容器场景产生误报。

I'm not sure your analysis is correct. If the entries appear in /proc/self/cgroup then that means the groups are mounted and active. The output from the mount command also shows that the v1 cgroup hierarchies are mounted.

I think the important distinction here is the container's namespace.

Droidspaces provides each container with its own cgroup hierarchy and supports both cgroup v1 and v2. However, from inside the container, the cgroup information visible through "/proc/self/cgroup" does not necessarily mean that the corresponding v1 hierarchy is actually accessible to processes in that namespace.

In my case, "/proc/self/cgroup" shows several v1 entries, but there are no v1 mounts visible with "findmnt -t cgroup", while cgroup2 is mounted and accessible at "/sys/fs/cgroup".

So I'm not suggesting that v1 is fake or that dinit should always prefer v2. I'm suggesting that dinit check whether the v1 hierarchy is actually usable from its current namespace. If it is usable, the existing v1 behavior should remain unchanged; if it isn't, dinit could skip it and use the available v2 hierarchy.

That way, normal bare-metal v1 setups are unaffected, while isolated/container environments can still work correctly.

You could also test this behavior using a Droidspaces container.

Do you have in mind some simple way to test whether a cgroups v1 hierarchy is usable?

I tested this in Droidspaces with two configurations.

1. With cgroup v1 forced on: "/proc/self/cgroup" contains the v1 entries, and "/proc/self/mountinfo" shows the corresponding "cgroup" v1 mounts (cpuset, cpu, memory, freezer, etc.). In this case, v1 is actually available, so the existing behavior should be preserved.

2. Without forcing cgroup v1: "/proc/self/cgroup" still contains the same v1 entries, but "/proc/self/mountinfo" has no "- cgroup" entries at all. The only cgroup filesystem mounted is "cgroup2". In this case, the v1 hierarchies are not available in the container's mount namespace.

So, at least in this environment, checking "/proc/self/mountinfo" for an actual cgroup v1 mount seems like a simple way to distinguish whether the v1 hierarchy is usable.

You can also test this directly in a Droidspaces environment, where these two configurations can be reproduced by enabling or disabling the forced cgroup v1 option.

For reference, snapd encountered a very similar cgroup v1/v2 detection issue on Ubuntu 22.04 and eventually fixed it. In that case, "/proc//cgroup" still reported a v1 hierarchy even though the v1 hierarchy was not actually mounted or usable. This seems like a useful precedent for handling the same situation in dinit: a v1 entry in "/proc/self/cgroup" does not necessarily mean that the v1 hierarchy is usable in the current mount namespace.

I will think about this more after the 1.0 release. It's not high priority. I would like to avoid parsing another system file (/proc/self/mountinfo) if possible.

Note that the warning just means Dinit can't determine a "current" croup which allows it to resolve relative cgroup names. It's perfectly possible to specify an absolute cgroup for services which run in a cgroup, and that's preferable for system-level services anyway.

Got it, I understand. This issue can stay open for re‑evaluation after 1.0. Thanks for looking into it.