Changes

== 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. It's a wrapper, use it the same way you use regular criu binary, all command line options are the same.

== Known issues ==

== Dumping processes restored by criu-ns ==

 

 

== Limitations ==

# 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)