[CRIU] [PATCH] Fix restoring cgroup across hosts

[Hui Kang]

On Mon, Aug 10, 2015 at 12:58 PM, Pavel Emelyanov <xemul at parallels.com>
wrote:

> On 08/10/2015 07:43 PM, Hui Kang wrote:
> >
> >
> > On Mon, Aug 10, 2015 at 12:35 PM, Pavel Emelyanov <xemul at parallels.com
> <mailto:xemul at parallels.com>> wrote:
> >
> >     On 08/10/2015 06:00 PM, Hui Kang wrote:
> >     > The process to be restored may not have certain cgroup dir, e.g
> >     > cpu/[PID]/cpu.shares. Currently restoring  will fail in closing
> >     > the file. If this is the case, the fileno is -1 and we can ignore
> >     > this and let the restore proceed.
> >
> >     If the file is missing then the fopen() itself should return -1.
> >
> > Hi, Pavel
> > The file is not missing in the destination, e.g., cpu/cpu.shares. The
> open and write are
> > successful, e.g., fileno returning 5. Only fclose return error. But if
> you check fileno(f)
> > after fclose, it returns -1. That's why I added the additional check for
> this.
>
> I see, but this means, that we have actually failed to restore the cgroup
> property.
> I would find out why write() fails, that's the real bug we have.
>

I found that it always fails to write into the top level of cgroups, e.g.,
echo "1024" > /sys/fs/cgroup/cpu/cpu.share.

However, when using manage-cgroup=full to restore a process, criu will try
to propagate these files, so the write will fail. The reason fprintf
returns success is because the data actually has not been flushed to the
file (although cgroup is a virtual file system). So I submitted another
patch to fix this (see
http://lists.openvz.org/pipermail/criu/2015-August/021743.html)

- Hui





>
> -- Pavel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150812/9aeb99d1/attachment.html>