Difference between revisions of "Tree after restore"
Jump to navigation
Jump to search
m |
m (→See also) |
||
Line 49: | Line 49: | ||
* [[C/R in namespace]] | * [[C/R in namespace]] | ||
− | [[Category: | + | [[Category:API]] |
Revision as of 16:01, 20 September 2016
The restore command has several options how to restore the tree.
Types of restore
- Default
- CRIU just forks the root task and all other tasks, restores the tasks, then waits for it to exit and after it exits itself. The process tree right after restore is shown on the picture below.
- Detached
- An option
--restore-detached
makes CRIU exit right after restoring the tree thus causing it to get reparented to the init process.
- Sibling
- An option
--restore-sibling
makes CRIU create root task as its own sibling and thus as caller's child. After restore is complete CRIU also exits thus leaving the restored tree being a pure child of the caller.
Doing execv() in CRIU
In the default restore case it's possible to replace CRIU hanging between the caller process and the root one with something more useful. The --exec-cmd
option makes CRIU call execv() with arguments that are to be given at the very end of the CLI after --
argument. E.g. like this
criu restore --images-dir img/ --exec-cmd -v4 -o restore.log -- my_waiter --my-waiter-arg
In this case the restored tree will look like in default case, but with the custom binary instead of CRIU processes.
Getting pid of the tree
In case the process tree lives in namespaces or is restored in new namespaces, the real pid of the root task can become any. Knowing it depends on the API used.
- CLI
- When using the
--pidfile $path
option CRIU writes the PID of the root task in the$path
file.
- RPC
- In case of RPC the real pid of restored root task is reported back in the
criu_resp.restore.pid
field of the message.