Changes

66 bytes removed ,  22:38, 8 September 2016
rewording
Line 3: Line 3:  
== Problem ==
 
== Problem ==
   −
When restoring a process tree without namespaces (i.e. -- into the namespaces in which criu lives) one may frequently hit a "pid mismatch" problem. It is when a process we'd like 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 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
   −
And 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.
+
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. Just replace running one instead of regular criu run would do all of this, there's no need in doing anything with the CLI options, the API is fully compatible.
+
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. Use it the same way you use regular criu binary, all command line options are the same.
   −
== Known issues ==
+
== Limitations ==
   −
# The [[Advanced usage#shell jobs C.2R|shell jobs]] are not supported
+
# [[Advanced usage#shell jobs C.2R|Shell jobs]] are not supported
 
# The [[RPC#Swrk mode|swrk mode]] is not supported
 
# The [[RPC#Swrk mode|swrk mode]] is not supported
# Only the dump and restore is supported, so no [[Incremental dumps]] possible yet
+
# Only the dump and restore are supported ([[incremental dumps]] are not possible)
    
[[Category:API]]
 
[[Category:API]]
 
[[Category:HOWTO]]
 
[[Category:HOWTO]]