Difference between revisions of "CR in namespace"

From CRIU
Jump to navigation Jump to search
m
(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]]

Revision as of 22:38, 8 September 2016

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.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:

  1. In the new pid namespace, someone has to become the "init" process
  2. 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

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. Use it the same way you use regular criu binary, all command line options are the same.

Limitations

  1. Shell jobs are not supported
  2. The swrk mode is not supported
  3. Only the dump and restore are supported (incremental dumps are not possible)