[systemd-devel] [RFC] [PATCH] cgroup: don't trim cgroup trees created by someone else

[Lennart Poettering]

On Fri, 19.09.14 17:14, Michal Sekletar (msekleta at 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