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: 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 ___ 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 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 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: 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. 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
[systemd-devel] [RFC] [PATCH] cgroup: don't trim cgroup trees created by someone else
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.
---
Reproducer:
1) start qemu-kvm VM via virsh/virt-manager
2) ls /sys/fs/cgroup/memory /* see machine.slice cgroup */
3) verify that scope unit for VM has MemoryAccounting=no
4) systemctl daemon-reload
5) systemctl restart some_service
6) ls /sys/fs/cgroup/memory /* see machine.slice cgroup gone */
To be honest I have no idea if the approach taken here is correct, however
it fixes the bug at least on my machine.
src/core/cgroup.c| 2 +-
src/shared/cgroup-util.c | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 6c6e4f5..8ede79a 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -780,7 +780,7 @@ void unit_destroy_cgroup(Unit *u) {
if (!u-cgroup_path)
return;
-r = cg_trim_everywhere(u-manager-cgroup_supported, u-cgroup_path,
!unit_has_name(u, SPECIAL_ROOT_SLICE));
+r = cg_trim_everywhere(u-cgroup_realized_mask, u-cgroup_path,
!unit_has_name(u, SPECIAL_ROOT_SLICE));
if (r 0)
log_debug(Failed to destroy cgroup %s: %s, u-cgroup_path,
strerror(-r));
diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index da8e885..a19b5b4 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -1615,8 +1615,6 @@ int cg_create_everywhere(CGroupControllerMask supported,
CGroupControllerMask ma
NULSTR_FOREACH(n, mask_names) {
if (mask bit)
cg_create(n, path);
-else if (supported bit)
-cg_trim(n, path, true);
bit = 1;
}
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
