Difference between revisions of "Checkpoint/Restore"

From CRIU
Jump to navigation Jump to search
(crtools -> criu)
Line 3: Line 3:
 
=== Checkpoint ===
 
=== Checkpoint ===
  
The checkpoint procedure relies heavily on '''/proc''' file system (it's a general place where crtools 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
 
Which includes
  

Revision as of 16:46, 30 April 2013

Basic design

Checkpoint

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

  • Files descriptors information (via /proc/$pid/fd and /proc/$pid/fdinfo).
  • Pipes parameters.
  • Memory maps (via /proc/$pid/maps).

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

  1. $pid of a process group leader is obtained from the command line.
  2. By using this $pid the dumper walks though /proc/$pid/task/$tid/children and gathers children $pids recursively. At the end we will have a process tree.
  3. Then we take every $pid from a process tree, seize and them with ptrace PTRACE_SEIZE call (which put tasks into seized state, where tasks do not know that they are actually stopped and someone does nasty things with them :), and performs the following steps on each $pid.
  4. Collect VMA areas by parsing /proc/$pid/maps.
  5. Collect file descriptor numbers the task has via /proc/$pid/fd.
  6. Core parameters of a task (such as registers and friends) are being dumped via ptrace interface and parsing /proc/$pid/stat entry.
  7. The dumper injects a parasite code into a task via ptrace interface. This is done in two steps - at first we inject only a few bytes for mmap syscall at CS:IP the task has at moment of seizing. Then ptrace allow us to run an injected syscall and we allocate enough memory for a parasite code chunk we need for dumping. After that the parasite code is copied into new place inside dumpee address space and CS:IP set respectively to point to our parasite code.
  8. After everything dumped (such as memory pages, which can be written out only from inside dumpee address space) we use ptrace facility again and cure dumpee by dropping out all our parasite code and restoring original code.
  9. The procedure continues for every $pid.

Restore

The restore procedure (aka restorer) proceed in the following steps

  1. A process tree has been read from a file.
  2. Every process started with saved (i.e. original) $pid via clone() call.
  3. Files and pipes are restored (by restored it's meant - they are opened and positioned).
  4. A new memory map is created, filled with data the program had at checkpoint time.
  5. Finally the program is kicked to start with rt_sigreturn system call.