CRIU

Changes

Final states (edit)

Revision as of 17:43, 29 August 2016

272 bytes added ,  17:43, 29 August 2016
reworked a bit
Line 1: Line 1: −
Final state is the state that ps tree will have after its dump or restore.
+
Final state is the state a process tree ends up in after CRIU dump or restore.
   −
There are 3 possible final states in CRIU:
+
There are 3 possible final states:
−
# 'Running' (ps tree is executed as usual)
+
; Running : processes are running as usual
−
# 'Stopped' (ps tree is stopped using SIGSTOP)
+
; Stopped : processes are stopped using SIGSTOP
−
# 'Dead' (ps tree is destroyed using SIGKILL)
+
; Dead   : processes are destroyed using SIGKILL
   −
== CLI options for changing of process tree final state ==
+
== Changing the default final states ==
−
You can use --leave-stopped option with CRIU dump/restore commands to set process tree final state to 'Stopped'.
     −
Use --leave-running option to set final state to 'Running'.
+
You can use the following command line options with CRIU dump and restore commands
 +
to change the default process tree final state:
   −
== Process tree final state after CRIU dump command ==
+
* <code>--leave-stopped</code>
 +
* <code>--leave-running</code>
   −
By default final state of process tree after dump is 'Dead'.
+
== criu dump ==
−
So CRIU will kill process tree after it was dumped. But why? Suppose you leave your
  −
process tree running after it was dumped. What if it deleted some files it was using
  −
during its dump? What if it closed some tcp connections? After that CRIU won't be able
  −
to restore process tree from the dump it has created earlier.
  −
System simply won't have resources that this process tree requires at
  −
the moment captured in dump.
     −
If your process tree doesn't destroy resources it depended on before dump then you'll be able to restore it after dump with --leave-running option.
+
By default, the final state of a process tree after <code>criu dump</code> is ''dead'',
−
But be aware that your process tree left running after dump may modify some state (for example a file) in way not compatible on application level with process tree restored from this dump later.
+
meaning CRIU kills the process tree right after dumping it.
   −
What about leaving process tree stopped after dump was performed? When it is needed?
+
Such a default makes lot of sense. Suppose the process tree is left running after being dumped.
−
It may be needed for debugging of CRIU. If CRIU wasn't accurate during dump command
+
If processes are left running, they will most probably change the filesystem state (for example,
−
then it would leave some traces in dumped process tree. You can investigate such process tree in
+
delete a file) and/or networking state (for example, close a TCP connection). After such changes
−
stopped state. You'll probably find some other use cases for --leave-stopped option with CRIU dump command.
+
CRIU won't be able to restore the process tree from the dump, as the system simply won't have
 +
resources that this process tree requires at the moment when it was captured.
   −
Leaving process tree running is necessary for predump command and currently --leave-stopped and
+
On the contrary, if a process tree does not destroy any resources it depended upon before dump,
−
--leave-running options have on effect on it.
+
then it is possible to restore it after dump made with <code>--leave-running</code> option.
 +
Be aware, though, that the process tree left running after the dump may modify some state
 +
(for example, write to a file) in way that is not compatible on the application level with
 +
the process tree restored from this dump later.
   −
== Process tree final state after CRIU restore command ==
+
Now, let's consider leaving the process tree stopped after performing the dump.
−
By default final state of process tree after restore is 'Running'. That's because you usually
+
One possible use case for that is CRIU debugging. If CRIU was not quite accurate doing dump,
−
want to immediately start execution of process tree after its restore. You can use --leave-stopped
+
then it would leave some traces in the dumped process tree. You can investigate such a process tree
−
option to restore process tree in 'Stopped' state.
+
in its stopped state. Surely you might find some other cases to use <code>--leave-stopped</code>.
   −
== Moving process tree from 'Stopped' state to 'Running' ==
+
Also, leaving the process tree running is naturally necessary for the <code>predump</code>
−
After criu has dumped/restored process tree in 'Stopped' state we sometimes need to continue
+
command, so currently <code>--leave-stopped</code> and <code>--leave-running</code> options
−
its execution putting process tree into 'Running' state. For this purpose use this [https://github.com/xemul/criu-scripts/blob/master/pstree_cont.py script]. It has only single argument - PID of process tree root.
+
are ignored for <code>predump</code>.
 +
 
 +
== criu restore ==
 +
 
 +
By default, the final state of a process tree after restore is ''running''. That's because one usually
 +
wants to immediately resume execution of the process tree after restore. One can use <code>--leave-stopped</code>
 +
option to restore the process tree and leave it in ''stopped' state.
 +
 
 +
== Changing the state from stopped to running ==
 +
 
 +
After criu dumped or restored a process tree and left it in ''stopped'' state,
 +
we may need to continue its execution, putting the process tree into ''running'' state.
 +
To do that, use the [https://github.com/xemul/criu-scripts/blob/master/pstree_cont.py pstree_cont.py]
 +
script. Its sole argument is the PID of a process tree root process.
    
[[Category: Under the hood]]
 
[[Category: Under the hood]]
 
[[Category: API]]
 
[[Category: API]]
Retrieved from "https://criu.org/Special:MobileDiff/3044"