Difference between revisions of "Final states"

From CRIU
Jump to navigation Jump to search
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= The concept of process tree final states =
+
Final state is the state a process tree ends up in after CRIU dump or restore.
  
Final state is the state that ps tree will have after its dump or restore.
+
There are 3 possible final states:
 +
; Running : processes are running as usual
 +
; Stopped : processes are stopped using SIGSTOP
 +
; Dead    : processes are destroyed using SIGKILL
  
There are 3 possible final states in CRIU:
+
== Changing the default final states ==
# 'Running' (ps tree is executed as usual)
 
# 'Stopped' (ps tree is stopped using SIGSTOP)
 
# 'Dead' (ps tree is destroyed using SIGKILL)
 
  
= CLI options for changing of process tree final state =
+
You can use the following command line options with CRIU dump and restore commands
You can use --leave-stopped option with CRIU dump/restore commands to set process tree final state to 'Stopped'.
+
to change the default process tree final state:
  
Use --leave-running option to set final state to 'Running'.
+
* <code>--leave-stopped</code>
 +
* <code>--leave-running</code>
  
= Process tree final state after CRIU dump command =
+
== criu dump ==
  
By default final state of process tree after dump is 'Dead'.
+
By default, the final state of a process tree after <code>criu dump</code> is ''dead'',
So CRIU will kill process tree after it was dumped. But why? Suppose you leave your
+
meaning CRIU kills the process tree right after dumping it.
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.
+
Such a default makes lot of sense. Suppose the process tree is left running after being dumped.
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.
+
If processes are left running, they will most probably change the filesystem state (for example,
 +
delete a file) and/or networking state (for example, close a TCP connection). After such changes
 +
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.
  
What about leaving process tree stopped after dump was performed? When it is needed?
+
On the contrary, if a process tree does not destroy any resources it depended upon before dump,
It may be needed for debugging of CRIU. If CRIU wasn't accurate during dump command
+
then it is possible to restore it after dump made with <code>--leave-running</code> option.
then it would leave some traces in dumped process tree. You can investigate such process tree in
+
Be aware, though, that the process tree left running after the dump may modify some state
stopped state. You'll probably find some other use cases for --leave-stopped option with CRIU dump command.
+
(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.
  
Leaving process tree running is necessary for predump command and currently --leave-stopped and
+
Now, let's consider leaving the process tree stopped after performing the dump.
--leave-running options have on effect on it.
+
One possible use case for that is CRIU debugging. If CRIU was not quite accurate doing dump,
 +
then it would leave some traces in the dumped process tree. You can investigate such a process tree
 +
in its stopped state. Surely you might find some other cases to use <code>--leave-stopped</code>.
  
= Process tree final state after CRIU restore command =
+
Also, leaving the process tree running is naturally necessary for the <code>predump</code>
By default final state of process tree after restore is 'Running'. That's because you usually
+
command, so currently <code>--leave-stopped</code> and <code>--leave-running</code> options
want to immediately start execution of process tree after its restore. You can use --leave-stopped
+
are ignored for <code>predump</code>.
option to restore process tree in 'Stopped' state.
 
  
= Moving process tree from 'Stopped' state to 'Running' =
+
== criu restore ==
After criu has dumped/restored process tree in 'Stopped' state we sometimes need to continue
+
 
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.
+
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, changing the state to ''running''.
 +
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]]

Latest revision as of 17:44, 29 August 2016

Final state is the state a process tree ends up in after CRIU dump or restore.

There are 3 possible final states:

Running
processes are running as usual
Stopped
processes are stopped using SIGSTOP
Dead
processes are destroyed using SIGKILL

Changing the default final states[edit]

You can use the following command line options with CRIU dump and restore commands to change the default process tree final state:

  • --leave-stopped
  • --leave-running

criu dump[edit]

By default, the final state of a process tree after criu dump is dead, meaning CRIU kills the process tree right after dumping it.

Such a default makes lot of sense. Suppose the process tree is left running after being dumped. If processes are left running, they will most probably change the filesystem state (for example, delete a file) and/or networking state (for example, close a TCP connection). After such changes 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.

On the contrary, if a process tree does not destroy any resources it depended upon before dump, then it is possible to restore it after dump made with --leave-running 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.

Now, let's consider leaving the process tree stopped after performing the dump. One possible use case for that is CRIU debugging. If CRIU was not quite accurate doing dump, then it would leave some traces in the dumped process tree. You can investigate such a process tree in its stopped state. Surely you might find some other cases to use --leave-stopped.

Also, leaving the process tree running is naturally necessary for the predump command, so currently --leave-stopped and --leave-running options are ignored for predump.

criu restore[edit]

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 --leave-stopped option to restore the process tree and leave it in stopped' state.

Changing the state from stopped to running[edit]

After criu dumped or restored a process tree and left it in stopped state, we may need to continue its execution, changing the state to running. To do that, use the pstree_cont.py script. Its sole argument is the PID of a process tree root process.