From OpenVZ Virtuozzo Containers Wiki
|
|
(9 intermediate revisions by one other user not shown) |
Line 1: |
Line 1: |
− | == What CRtools is ==
| + | See main article here [http://criu.org/CR_tools] |
− | | |
− | '''CRtools''' is an utility to checkpoint/restore process tree. Unlike checkpoint/restore implemented completely in kernel space,
| |
− | it tries to achieve the same target mostly in user space.
| |
− | | |
− | === Agenda ===
| |
− | | |
− | # Basic design (checkpoint == proc + SEIZE, restore == syscalls + execve)
| |
− | # What's required from kernel
| |
− | | |
− | == Basic design ==
| |
− | | |
− | === Checkpoint ===
| |
− | | |
− | The checkpoint procedure relies heavily on '''/proc''' file system (it's a general place where crtools 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 simply the dumper further) does the following steps during checkpoint stage:
| |
− | | |
− | # A '''$pid''' of a process group leader is obtained from the command line
| |
− | # By using this '''$pid''' the dumper walks though '''/proc/$pid/status''' and gathers children '''$pids''' recursively. At the end we will have a process tree.
| |
− | # Then it takes every '''$pid''' from a process tree, sends ''SIGSTOP'' to every process found, and performs the following steps on each '''$pid'''
| |
− | #* Collects VMA areas by parsing '''/proc/$pid/maps'''
| |
− | #*
| |
Latest revision as of 20:31, 17 December 2011
See main article here [1]