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

[Hui Kang]

On Thu, Aug 27, 2015 at 1:12 PM, Andrey Wagin <avagin at gmail.com> wrote:
> 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.

I run criu dump on another ssh login too. But my experiment is on
ubuntu, which does not use systemD. Is this the reason I have such
issue?

- Hui

>
>>
>> - 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