Difference between revisions of "CR in namespace"
(Created page with "This page describes the criu-ns script that has appeared in criu-dev branch after 2.5 and is aimed at 2.6. == Problem == When restoring a process tree without namespaces (i....") |
m (→Limitations: Shell jobs are supported by the 'criu-ns' script) |
||
| (6 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | This page describes the criu-ns script that has appeared in criu-dev branch after 2.5 and is aimed at 2.6. | + | This page describes the <code>criu-ns</code> script that has appeared in criu-dev branch after 2.5 and is aimed at 2.6. |
== Problem == | == Problem == | ||
| − | When restoring a process tree without namespaces (i.e. | + | When restoring a process tree without [[namespaces]] (i.e. into namespaces in which criu lives) one may frequently hit a "pid mismatch" problem. It happens when a process CRIU tries to restore has a PID which is already owned by some other process living in this pid namespace. There's no way one can restore a process tree in ''this'' namespace, so the only solution is to unshare the new pid namespace and restore the tree into it. |
| − | When doing so we have two problems | + | When doing so we have two problems: |
| − | # In the new pid namespace someone has to become the "init" process | + | # In the new pid namespace, someone has to become the "init" process |
| − | # In the new pid namespace we'd need to have new /proc mount which implies unsharing the mount namespace as well | + | # In the new pid namespace, we'd need to have new /proc mount which implies unsharing the mount namespace as well |
| − | + | Even if one solves the above problems, there will appear the third one -- when trying to dump the restore process tree ''again'' criu will likely refuse to dump the mount namespace, as it will be a complete clone of the original one and thus would likely contain many many unsupported mounts such as real devices, securityfs, trace/debug-fs etc. The latter can still be solved by nsenter-ing the process' pid and mount namespaces and doing the dump. | |
== Solution == | == Solution == | ||
| − | All of the above -- the need to unshare stuff, getting pseudo-init, re-mounting /proc on dump and setns-ing on restore -- is solved by the scripts/criu-ns script. | + | All of the above -- the need to unshare stuff, getting pseudo-init, re-mounting /proc on dump and setns-ing on restore -- is solved by the <code>scripts/criu-ns</code> script. It's a wrapper, use it the same way you use regular criu binary, all command line options are the same. |
| − | == | + | == Dumping processes restored by criu-ns == |
| − | # The [[ | + | Note that if you want to dump process trees that were restored by <code>criu-ns</code>, you need to use <code>criu-ns dump</code>. |
| − | # | + | |
| − | # Only the dump and restore | + | == Limitations == |
| + | |||
| + | # The [[RPC#Swrk mode|swrk mode]] is not supported | ||
| + | # Only the dump and restore are supported ([[incremental dumps]] are not possible) | ||
| + | |||
| + | [[Category:API]] | ||
| + | [[Category:HOWTO]] | ||
Latest revision as of 09:04, 30 September 2019
This page describes the criu-ns script that has appeared in criu-dev branch after 2.5 and is aimed at 2.6.
Problem[edit]
When restoring a process tree without namespaces (i.e. into namespaces in which criu lives) one may frequently hit a "pid mismatch" problem. It happens when a process CRIU tries to restore has a PID which is already owned by some other process living in this pid namespace. There's no way one can restore a process tree in this namespace, so the only solution is to unshare the new pid namespace and restore the tree into it.
When doing so we have two problems:
- In the new pid namespace, someone has to become the "init" process
- In the new pid namespace, we'd need to have new /proc mount which implies unsharing the mount namespace as well
Even if one solves the above problems, there will appear the third one -- when trying to dump the restore process tree again criu will likely refuse to dump the mount namespace, as it will be a complete clone of the original one and thus would likely contain many many unsupported mounts such as real devices, securityfs, trace/debug-fs etc. The latter can still be solved by nsenter-ing the process' pid and mount namespaces and doing the dump.
Solution[edit]
All of the above -- the need to unshare stuff, getting pseudo-init, re-mounting /proc on dump and setns-ing on restore -- is solved by the scripts/criu-ns script. It's a wrapper, use it the same way you use regular criu binary, all command line options are the same.
Dumping processes restored by criu-ns[edit]
Note that if you want to dump process trees that were restored by criu-ns, you need to use criu-ns dump.
Limitations[edit]
- The swrk mode is not supported
- Only the dump and restore are supported (incremental dumps are not possible)