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

[Lennart Poettering]

On Mon, 03.11.14 17:27, Michal Sekletar (msekleta at redhat.com) wrote:

> On Tue, Oct 21, 2014 at 09:16:16PM +0200, Lennart Poettering wrote:
> > On Fri, 19.09.14 17:14, Michal Sekletar (msekleta at redhat.com) wrote:
> > 
> <snip> 
> > 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. 
> 
> I think I grok what are you proposing, however according to developments in 
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1139223
> 
> it doesn't seem to be correct solution either. systemd will happily remove cgroup
> in which there are processes.

Oh. right, systemd is stricter there than I remembered: we will
actually migrate the PIDs before removing the cgroup.

I figure we need to figure out a way how we can make a cgroup capable
for embedding their own systemd instances, so that the controller
memberships cover all hierarchies.

I need to think about this.

Lennart

-- 
Lennart Poettering, Red Hat