1. It is relatively complicated to use. And even harder to use properly. From what I understand, to reliably kill all processes you need to freeze the cgroup then list the pids in it, then send a signal to each of those pids. Which is pretty involved, requires a separate supervisor process, and isn't 100% reliable in cgroupv1.
2. It requires root, or at least having control of a cgroup delegated to the process. You might be able to use user namespaces, depending on the distro and kernel, but that makes the implementation even more complicated.
3. It is possible to escape the cgroup, if the child process has permission to write to the task file of another cgroup.
Cgroups are useful, and can be used for this use case in some common scenarios, such as docker and systemd.
But as a general tool for structured concurrency that normal processes can use, it doesn't quite fit the bill.
its sort of weird to think that the notion that portability with respect to cgroups is now primarily about whether your version of the linux kernel supports the revision of cgroups that you're concerned about, rather than that you have a kernel that understands cgroups.
Two. And what's funny, I saw some of the fallout from the transition from v1 to v2 only last year at my last gig. Company upgraded Debian and Debian maintainers opted to go v2 only in the kernel build. However, the version of JVM the company was using did not fully support v2. Without the cgroup support, each JVM in a container thought they had the resources of the whole system. It was a cluster (heh) fuck, as in that all of the affected services OOM'd thinking they had more heap potential and the k8s cluster was churning pods like no tomorrow.
1. It is relatively complicated to use. And even harder to use properly. From what I understand, to reliably kill all processes you need to freeze the cgroup then list the pids in it, then send a signal to each of those pids. Which is pretty involved, requires a separate supervisor process, and isn't 100% reliable in cgroupv1.
2. It requires root, or at least having control of a cgroup delegated to the process. You might be able to use user namespaces, depending on the distro and kernel, but that makes the implementation even more complicated.
3. It is possible to escape the cgroup, if the child process has permission to write to the task file of another cgroup.
Cgroups are useful, and can be used for this use case in some common scenarios, such as docker and systemd.
But as a general tool for structured concurrency that normal processes can use, it doesn't quite fit the bill.