Difference between revisions of "Final states"
(created) |
|||
| Line 1: | Line 1: | ||
| − | + | = The concept of process tree final states = | |
| + | |||
| + | Final state is the state that ps tree will have after its dump or restore. | ||
| + | |||
| + | There are 3 possible final states in CRIU: | ||
| + | # '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 --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'. | ||
| + | |||
| + | = Process tree final state after CRIU dump command = | ||
| + | |||
| + | By default final state of process tree after dump is 'Dead'. | ||
| + | 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. | ||
| + | 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. | ||
| + | |||
| + | What about leaving process tree stopped after dump was performed? When it is needed? | ||
| + | It may be needed for debugging of CRIU. If CRIU wasn't accurate during dump command | ||
| + | then it would leave some traces in dumped process tree. You can investigate such process tree in | ||
| + | stopped state. You'll probably find some other use cases for --leave-stopped option with CRIU dump command. | ||
| + | |||
| + | Leaving process tree running is necessary for predump command and currently --leave-stopped and | ||
| + | --leave-running options have on effect on it. | ||
| + | |||
| + | = Process tree final state after CRIU restore command = | ||
| + | By default final state of process tree after restore is 'Running'. That's because you usually | ||
| + | want to immediately start execution of process tree after its restore. You can use --leave-stopped | ||
| + | option to restore process tree in 'Stopped' state. | ||
| + | |||
| + | = Moving process tree from 'Stopped' state to 'Running' = | ||
| + | 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. | ||
| + | |||
| + | [[Category: Under the hood]] | ||
Revision as of 18:35, 26 August 2016
The concept of process tree final states
Final state is the state that ps tree will have after its dump or restore.
There are 3 possible final states in CRIU:
- '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 --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'.
Process tree final state after CRIU dump command
By default final state of process tree after dump is 'Dead'. 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. 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.
What about leaving process tree stopped after dump was performed? When it is needed? It may be needed for debugging of CRIU. If CRIU wasn't accurate during dump command then it would leave some traces in dumped process tree. You can investigate such process tree in stopped state. You'll probably find some other use cases for --leave-stopped option with CRIU dump command.
Leaving process tree running is necessary for predump command and currently --leave-stopped and --leave-running options have on effect on it.
Process tree final state after CRIU restore command
By default final state of process tree after restore is 'Running'. That's because you usually want to immediately start execution of process tree after its restore. You can use --leave-stopped option to restore process tree in 'Stopped' state.
Moving process tree from 'Stopped' state to 'Running'
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 script. It has only single argument - PID of process tree root.