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 bef
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
> >
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 fo
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.
S
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/memor
