Changes

The checkpoint procedure relies heavily on '''/proc''' file system (it's a general place where criu takes all the information it needs).

The checkpoint procedure relies heavily on '''/proc''' file system (it's a general place where criu takes all the information it needs).

Which includes

The information gathered from /proc includes:

* Files descriptors information (via '''/proc/$pid/fd''' and '''/proc/$pid/fdinfo''').

* Files descriptors information (via '''/proc/$pid/fd''' and '''/proc/$pid/fdinfo''').

* etc.

* etc.

The process dumper (lets call it a dumper further) does the following steps during checkpoint stage

The process dumper (called a dumper below) does the following steps during the checkpoint stage.

=== Collect process tree and freeze it ===

=== Collect process tree and freeze it ===

The '''$pid''' of a process group leader is obtained from the command line (<code>--tree</code> option). By using this '''$pid''' the dumper walks though '''/proc/$pid/task/''' directory collecting threads and through the '''/proc/$pid/task/$tid/children''' to gathers children recursively. While walking tasks are stopped using the <code>ptrace</code>'s <code>PTRACE_SEISE</code> command.

The '''$pid''' of a process group leader is obtained from the command line (<code>--tree</code> option). By using this '''$pid''' the dumper walks though '''/proc/$pid/task/''' directory collecting threads and through the '''/proc/$pid/task/$tid/children''' to gathers children recursively. While walking tasks are stopped using the <code>ptrace</code>'s <code>PTRACE_SEIZE</code> command.

 

=== Collect tasks' resources and dump them ===

=== Collect tasks' resources and dump them ===

# threads

# threads

These for are delayed till the last stage for the reasons described further. On this stage CRIU opens files, prepares namespaces, maps (and fills with data) private memory areas, creates sockets, calls chdir() and chroot() and dome some more.

The restoration of the above four types of resources are delayed till the last stage for the reasons described below. On this stage CRIU opens files, prepares [[namespaces]], maps (and fills with data) private memory areas, creates sockets, calls chdir() and chroot() and doing some more.

 

=== Switch to [[restorer context]], restore the rest and continue ===

The reason for restorer blob is simple. Since criu morphs into the target process, it will have to unmap all its memory and put back the target one. While doing so, some code should exist in memory (the code doing the munmap and mmap). Therefore, the restorer blob is introduced. It's a small piece of code, that doesn't intersect with criu mappings AND target mappings. At the end of stage 2 criu jumps into this blob and restores the memory maps.

The reason for restorer blob is simple. Since criu morphs into the target process, it will have to unmap all its memory and put back the target one. While doing so some code should exist in memory (the code doing the munmap and mmap). So we introduced the restorer blob -- the small piece of code, that doesn't intersect with criu mappings AND target mappings. At the end of stage 2 criu jumps into this blob and restores the memory maps.

At the same place we restore timers not to make them fire too early, here we restore credentials to let criu do privileged operations (like fork-with-pid) and threads not to make them suffer from sudden memory layout change.

At the same place we restore timers not to make them fire too early, here we restore credentials to let criu do priveledged operations (like fork-with-pid) and threads not to make them suffer from sudden memory layout change.

''See also: [[restorer context]], [[tree after restore]].''

[[Category:Under the hood]]

[[Category:Under the hood]]