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

[Andrew Vagin]

On Thu, Aug 27, 2015 at 01:17:09PM -0400, Hui Kang wrote:
> 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?

Yes.

> 
> - 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
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu