Demi Marie Obenour writes: > On 7/27/26 08:11, Alyssa Ross wrote: >> Demi Marie Obenour writes: >> >>> Actually use the cgroup manager for the first time. >>> >>> Signed-off-by: Demi Marie Obenour >>> --- >>> host/rootfs/image/etc/init | 4 ++++ >>> 1 file changed, 4 insertions(+) >>> >>> diff --git a/host/rootfs/image/etc/init b/host/rootfs/image/etc/init >>> index 8ec7859ab00e24007a93d4000c8f34e353de50ae..5d31a23bae2f29f35bfeced68242dededf6ae0c7 100755 >>> --- a/host/rootfs/image/etc/init >>> +++ b/host/rootfs/image/etc/init >>> @@ -12,4 +12,8 @@ if { /bin/ln -s /proc/self/fd/2 /dev/stderr } >>> if { /bin/mount --make-shared / } >>> if { /bin/mount -a --mkdir } >>> >>> +# Enable subtree control of all cgroups and move >>> +# process to a child cgroup. >>> +/usr/bin/cgroup-setup --init-subtree . >>> + >>> /bin/s6-linux-init -c /etc/s6-linux-init -s /run/param -- $@ >>> >> >> Why do we need this? Isn't the root cgroup an exception to the "no >> internal processes" rule? > > It is indeed exempt, though as systemd does create a sub-cgroup for > itself (init.scope) I don't know if the corresponding code paths in the > kernel are well-tested. However, enabling controllers *is* necessary. > If you'd prefer, I can use sed for that. I'd prefer to leave things as they come unless we have a reason not to. I wonder if there's a technical reason for systemd to do that, or if it just fit into their design better? If you can write a comment explaining why we need a cgroup, then this is fine; otherwise let's stick to what's strictly necessary.