[CRIU] Restore failed. Exit code: 43

Paschalis Mpeis paschalis.mpeis at ed.ac.uk
Tue Jan 27 06:23:05 PST 2015


On Tue, Jan 27, 2015 at 12:57 PM, Pavel Emelyanov <xemul at parallels.com>
wrote:

> On 01/27/2015 03:48 PM, Paschalis Mpeis wrote:
> >
> >
> > On Tue, Jan 27, 2015 at 12:05 PM, Pavel Emelyanov <xemul at parallels.com
> <mailto:xemul at parallels.com>> wrote:
> >
> >     On 01/26/2015 08:05 PM, Paschalis Mpeis wrote:
> >     > My initial thought was to fork the initial process, so as to
> exploit the copy-on-write fork implementation on Linux.
> >     >
> >     > Then the forked process will call the function, and the parent
> will make the dump, by providing the PID of its child.
> >
> >     This would work, but will anyway dump the whole process. In order to
> dump only what it relevant
> >     to a single function... hmm... you should either explore the binary
> with disassembler or...
> >     maybe the memory tracked would help. You reset the tracker, then
> start working. Then you
> >     call criu to dump the process and dump only what memory has changed.
> This will include only
> >     what was touched by the function.
> >
> >
> > ​So, I should reset the bits of the used memory pages, so CRIU will dump
> only the "dirty" ones?
>
> Yes and no. Currently CRIU knows how to work with memory tracked, but the
> implementation of it is pretty strict -- you should provide criu with the
> "parent" image. In your case you do the single dump, so there's no parent
> image and criu will always dump all the memory.

​
Hmmm.. on your project's homepage it is mentioned this:

> Using this tool, you can freeze a running application (or part of it) and
> checkpoint it to a hard drive as a collection of files.

​
So, the way to do this, is to dump twice, the parent and the children?
Then, there is a way to provide this to CRIU, so it can find the
differences, and provide a new images that contains only the changed bits?​
Is there a documentation, or can you provide some guidance on this? Or at
least the relevant source files, so I can have a look at them?




>
>
> Or I should modify parts also parts of the dump functionality?​
>
> Yes. Look at the mem.c generate_iovs() function. It generates the bitmap
> of pages that should be taken into the image.
>

​Is this the function that excludes the pages of the parent?
Am I going to use the incremental dump feature of CRIU?
For example:
.dump1: parent process. ​
.dump2: child process (incremental)

So, on restore I 'll have to make it work on non-complete image files? ​How
hard will this be?
Is there anything else that I should know so as to do this?

Thank you very much, Pavel!​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150127/d38e42ff/attachment-0001.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150127/d38e42ff/attachment-0001.ksh>


More information about the CRIU mailing list