[CRIU] Restore failed. Exit code: 43

[Pavel Emelyanov]

On 01/27/2015 05:23 PM, Paschalis Mpeis wrote:
> On Tue, Jan 27, 2015 at 12:57 PM, Pavel Emelyanov <xemul at parallels.com <mailto: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> <mailto: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.
> 
> 

Ah, I see. We meant here that if an application consists of several processes, you can
dump any subtree of them. So CRIU granularity is "processes".

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

There's already a way to get memory difference -- it's called soft-dirty bits in the kernel.
CRIU uses them in generate_iovs() call mentioned.

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

Sure. We have an article http://criu.org/Memory_changes_tracking. It briefly describes
what it is and have links on other stuff. And all this functionality sits in the criu's
mem.c source file, the generate_iovs() is the key routine.

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

It's the function that generates bitmap of pages to be dumped. If it sees that we
do incremental dump it may exclude some bits, that correspond to the pages, that
are in the previous image set.

> Am I going to use the incremental dump feature of CRIU?
> For example:
> .dump1: parent process. ​
> .dump2: child process (incremental)

I wouldn't do the dump of parent. It's enough just to reset the memory tracker
and dump what has changed. CRIU cannot be _asked_ to do it with CLI/RPC, but
it has all the code inside to do it. So it's currently the matter of fixing
the API.

> So, on restore I 'll have to make it work on non-complete image files? ​How hard will this be?

Yes, restore would have to be taught to do partial restore. I tried to estimate the
difficulty of this. So far this seems to me to be a lot of work, since criu doesn't
restore stuff _into_ a process, but rather re-creates itself to _become_ the process
it restored. I tried to collect the thoughts here http://criu.org/Applying_images

> Is there anything else that I should know so as to do this?

Yes, I think one important thing that hasn't been said yet is that the changes
tracking only works for memory. Open files, timers, cwd/root, sockets, etc. is always
dumped as a whole.

> Thank you very much, Pavel!​

You're welcome! :)

Thanks,
Pavel