Changes

Jump to navigation Jump to search
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]]

Navigation menu