On Fri, 19.09.14 17:14, Michal Sekletar (msekl...@redhat.com) wrote: Heya,
> In cases when there is a cgroup tree in a controller hierarchy which was > not created by us, but it looks like it was (i.e. cgroup path is the > same as the one in systemd's named hierarchy) we shouldn't delete > it. So, this is definitely not upstream material, as we need to move things towards the direction of systemd being the only writer. Downstream it's a different story though, possibly. In general we really need to make sure that we clean up things as we go, and that in particular when we move cgroups or turn off or on specific cgroup bits which might have the effect of turning off/on specific controllers for it. Note that cgroup membership for controllers is actually propagated both sidewides and towards the root of a tree. This means means systemd ends up adding removing units to controllers depending on configuration of units that are not directly related to it. Due to this we it's really dynamic when we add and remove cgroup controller memberships and we must agressively clean up memberships. I do see the usecase though for those projects. I'd probably suggest not to merge it for RHEL either. But instead I'd propose a different solution for software: make sure sure to always move a PID into a cgroup as soon as it is created, so that its removal is blocked. Or in other words: right before you need a cgroup to add yourself to it, create it, and expect that it might go away while you are not using it. To deal with the possible race condition of creating a cgroup which is immediately cleaned up by somebody else, try doing this in a loop, until you succeeded. That way things can always stay nicely cleaned up and things are robust towards other processing playing around in the cgroup tree. Hope that makes sense? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
