El dom, 12 de oct 2014 a las 9:49 , Marcin Szewczyk
<marcin.szewc...@wodny.org> escribió:
On Sun, Oct 12, 2014 at 06:09:46PM +0200, Marcin Szewczyk wrote:
On Sun, Oct 12, 2014 at 05:25:43PM +0200, Marcin Szewczyk wrote:
> cgmanager: DEBUG per_ctrl_move_pid_main: 31385, memory -
user.slice/user-1000.slice/session-c13.scope
>
> That means that when systemd-shim calls cgmanager to
MovePid/MovePidAbs
> it uses a special controller name "all". But it seems "all"
doesn't
> include some controllers -- for example "name=systemd".
>
> Questions are:
> 1) Should cgmanager move pid to "name=systemd" when called with
"all"
> controller?
So, I think it should and it would. I omitted very important line
from
my previous log:
cgmanager: DEBUG per_ctrl_move_pid_main: 31385, memory -
user.slice/user-1000.slice/session-c13.scope
cgmanager: Found no cgroup entry for pid 31388 controller memory
The thing is -- cgmanager jumps out from the "all" loop after some
problem with the "memory" controller. I do not know what to do with
it
yet.
I have applied a patch (attached) to cgmanager and everything seems to
work now. I will send it to cgmanager maintainer and upstream to ask
if
it makes sense.
Oh gosh, I figured out why I am unaffected. This is in my kernel
command line:
cgroup_enable=memory
It was there all along! Thanks for figuring this out.
Perhaps another good idea is to continue moving things and not just
break out with a failure right away, then report failure once
everything that can be moved is moved, you know?
Relevant code for that can be found here:
https://github.com/cgmanager/cgmanager/blob/bfca08381096d1be6a952a520d9207d04a3d88cc/cgmanager.c#L215
Best regards,
--
Cameron Norman
