[CRIU] [PATCH] Skip restoring certain cgroup root directories when using full mode

[Andrey Wagin]

2015-08-27 12:44 GMT-04:00 Hui Kang <hkang.sunysb at gmail.com>:
> On Thu, Aug 27, 2015 at 7:01 AM, Andrew Vagin <avagin at gmail.com> wrote:
>> On Wed, Aug 26, 2015 at 11:12:02PM -0400, Hui Kang wrote:
>>> On Wed, Aug 26, 2015 at 12:27 AM, Andrew Vagin <avagin at gmail.com> wrote:
>>> > On Tue, Aug 25, 2015 at 10:25:02PM -0400, Hui Kang wrote:
>>> >>
>>> >> Hi, Pavel
>>> >> I still have difficulty in producing the bug you described. I have
>>> >> /sys/fs/cgroup/cpuset (which is the root) and /sys/fs/cgroup/cpuset/A.
>>> >> I have added task 1001 to the root and 1002 to
>>> >> /sys/fs/cgroup/cpuset/A. The patch has no problem in restoring the the
>>> >> task in /A.
>>> >>
>>> >> If this is the not nested case you described, could you give more
>>> >> detailed about the case you think of? Thanks.
>>> >
>>> > I think I've reproduced this bug:
>>> > https://asciinema.org/a/cv3qlitwvvt2guyi2woaok056
>>>
>>> Hi, Andew,
>>> I created my own script to reproduce the bug of not restoring cpu
>>> share. The script is
>>>
>>> #! /bin/bash
>>> set -e -x
>>> echo $$
>>> mkdir -p /sys/fs/cgroup/cpu/A
>>> echo 512 > /sys/fs/cgroup/cpu/A/cpu.shares
>>> sleep 1000 &
>>> echo $! > /sys/fs/cgroup/cpu/A/tasks
>>> wait
>>> [ `cat /sys/fs/cgroup/cpu/A/cpu.shares` -ne 512 ] && echo FAIL
>>>
>>> It will create two pid, say the first is 18001 and the second is 18002.
>>> When I run
>>>
>>> criu dump -t 18001 -vvvv --log-file dump.log -j  --manage-cgroup=ful
>>>
>>> It gives me the error
>>>
>>> Dumping file-locks
>>> (00.028444)
>>> (00.028451) Dumping pstree (pid: 18672)
>>> (00.028458) ----------------------------------------
>>> (00.028466) Process: 18672(18672)
>>> (00.028506) Process: 18674(18674)
>>> (00.028516) ----------------------------------------
>>> (00.028619) Error (cgroup.c:807): cg: Non supported sub-cgroups found
>>> (00.028961) Unlock network
>>> (00.028983) Unfreezing tasks into 1
>>> (00.028994) Unseizing 18672 into 1
>>> (00.029081) Unseizing 18674 into 1
>>>
>>> I am using the criu from git. Do you know why this happens? Thanks.
>>
>> I have seen this error too.
>> CRIU and the root task live in the same set of cgroups.
>> CRIU expects that all task should live in this set of cgroups.
>> Pavel, could you explain this behaviour?
>>
>
> Hi, Andrew,
> I am just curious how you bypass this in your video demo : )

I execute criu from a second ssh session. SystemD creates a separate
group for each session.

>
> - Hui
>
>>         /*
>>          * Check whether root task lives in its own set as compared
>>          * to criu. If yes, we should not dump anything, but make
>>          * sure no other sets exist. The latter case can be supported,
>>          * but requires some trickery and is hardly needed at the
>>          * moment.
>>          */
>>
>>         if (root_cgset == criu_cgset) {
>>                 if (!list_is_singular(&cg_sets)) {
>>                         pr_err("Non supported sub-cgroups found\n");
>>                         return -1;
>>                 }
>>
>>
>>>
>>> - Hui
>>>
>>> >
>>> >>
>>> >> - Hui
>>> >>
>>> _______________________________________________
>>> CRIU mailing list
>>> CRIU at openvz.org
>>> https://lists.openvz.org/mailman/listinfo/criu