Re: [systemd-devel] [RFC] [PATCH] cgroup: don't trim cgroup trees created by someone else
On Wed, 05.11.14 12:27, Lennart Poettering (mzerq...@0pointer.de) wrote: > > 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. OK, after some thinking and some discussions and more thinking, I now added this: http://cgit.freedesktop.org/systemd/systemd/commit/?id=a931ad47a8623163a29d898224d8a8c1177ffdaf With this in place libvirt-lxc should just work, if it properly creates the root cgroup of is containers with machined's CreateMachine() call. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] [PATCH] cgroup: don't trim cgroup trees created by someone else
On Mon, 03.11.14 17:27, Michal Sekletar (msekl...@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 (msekl...@redhat.com) wrote: > > > > > 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] [PATCH] cgroup: don't trim cgroup trees created by someone else
On Tue, Oct 21, 2014 at 09:16:16PM +0200, Lennart Poettering wrote: > On Fri, 19.09.14 17:14, Michal Sekletar (msekl...@redhat.com) wrote: > > 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. > > That way things can always stay nicely cleaned up and things are > robust towards other processing playing around in the cgroup tree. I am not sure how can we make that possible (playing nicely in cgroup tree) for the time beeing until we are the only writer. > > Hope that makes sense? > > Lennart Michal > > -- > Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] [PATCH] cgroup: don't trim cgroup trees created by someone else
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
