Freezing the tree - Revision history

Xemul at 18:30, 15 March 2017

2017-03-15T18:30:46Z

Xemul at 09:23, 20 September 2016

2016-09-20T09:23:21Z

Xemul at 09:22, 20 September 2016

2016-09-20T09:22:54Z

Xemul at 08:35, 20 September 2016

2016-09-20T08:35:37Z

Xemul at 08:34, 20 September 2016

2016-09-20T08:34:34Z

Kir: rm level1 header, fix English, add see also

2016-09-19T23:37:38Z

rm level1 header, fix English, add see also

Cyrillos at 16:44, 19 September 2016

2016-09-19T16:44:52Z

Xemul: Created page with "Category:Under the hood Category:Empty articles"

2016-09-17T13:45:02Z

Created page with "Category:Under the hood Category:Empty articles"

New page

[[Category:Under the hood]]
[[Category:Empty articles]]

← Older revision		Revision as of 18:30, 15 March 2017
Line 22:		Line 22:

	[[Category:Under the hood]]		[[Category:Under the hood]]
−	~~[[Category:Empty articles]]~~

← Older revision		Revision as of 09:23, 20 September 2016
Line 1:		Line 1:
		+	== Introduction ==
		+
	Before we can start checkpointing processes, we have to make sure that they will not change their state. The latter not only includes opening new files, sockets, changing session and other, but also producing new children processes which, in turn, can escape from dumping procedure. In other words, the process tree itself and processes in it must be "immobilized" while we are dumping it. While sounds trivial in theory, it is problematic in real life. The checkpoint is supposed to be transparent to the application we are dumping, thus it must not notice any change in process state transition. Traditionally, processes are stopped with the stop signal, but doing so would disturb the process state.		Before we can start checkpointing processes, we have to make sure that they will not change their state. The latter not only includes opening new files, sockets, changing session and other, but also producing new children processes which, in turn, can escape from dumping procedure. In other words, the process tree itself and processes in it must be "immobilized" while we are dumping it. While sounds trivial in theory, it is problematic in real life. The checkpoint is supposed to be transparent to the application we are dumping, thus it must not notice any change in process state transition. Traditionally, processes are stopped with the stop signal, but doing so would disturb the process state.

← Older revision		Revision as of 09:22, 20 September 2016
Line 1:		Line 1:
−	~~[[Category:Under the hood]]~~
−	~~[[Category:Empty articles]]~~
−
	Before we can start checkpointing processes, we have to make sure that they will not change their state. The latter not only includes opening new files, sockets, changing session and other, but also producing new children processes which, in turn, can escape from dumping procedure. In other words, the process tree itself and processes in it must be "immobilized" while we are dumping it. While sounds trivial in theory, it is problematic in real life. The checkpoint is supposed to be transparent to the application we are dumping, thus it must not notice any change in process state transition. Traditionally, processes are stopped with the stop signal, but doing so would disturb the process state.		Before we can start checkpointing processes, we have to make sure that they will not change their state. The latter not only includes opening new files, sockets, changing session and other, but also producing new children processes which, in turn, can escape from dumping procedure. In other words, the process tree itself and processes in it must be "immobilized" while we are dumping it. While sounds trivial in theory, it is problematic in real life. The checkpoint is supposed to be transparent to the application we are dumping, thus it must not notice any change in process state transition. Traditionally, processes are stopped with the stop signal, but doing so would disturb the process state.

Line 21:		Line 18:

	* https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt		* https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt
		+
		+	[[Category:Under the hood]]
		+	[[Category:Empty articles]]

@@ Line 9: / Line 9: @@
 * Freezing them using [https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt freezer cgroup].
-==
+== Capturing with ptrace ==
 == External links ==
 * https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt

@@ Line 2: / Line 2: @@
 [[Category:Empty articles]]
-Before we can start checkpointing processes, we have to make sure that they will not produce new children processes which would escape from dumping procedure. In other words, the process tree must be persistent while we are dumping it. While sounds trivial in theory, it is problematic in real life. The checkpoint is supposed to be transparent to the application we are dumping, thus it must not notice any change in process state transition. Traditionally, processes are stopped with the stop signal. But we have a better choice - [https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt a freezer cgroup].
+Before we can start checkpointing processes, we have to make sure that they will not change their state. The latter not only includes opening new files, sockets, changing session and other, but also producing new children processes which, in turn, can escape from dumping procedure. In other words, the process tree itself and processes in it must be "immobilized" while we are dumping it. While sounds trivial in theory, it is problematic in real life. The checkpoint is supposed to be transparent to the application we are dumping, thus it must not notice any change in process state transition. Traditionally, processes are stopped with the stop signal, but doing so would disturb the process state.
 == External links ==
 * https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt

← Older revision		Revision as of 16:44, 19 September 2016
Line 1:		Line 1:
	[[Category:Under the hood]]		[[Category:Under the hood]]
	[[Category:Empty articles]]		[[Category:Empty articles]]
		+
		+	= Overview =
		+
		+	Before we can start checkpointing processes we have to be sure that they will not produce new children processes which would escaped from dumping procedure. In other words the process tree must be persistent while we are dumping it. While sounds trivial in became problematic in real life. The checkpoint it supposed to be transparent to the application we are dumping thus it must not notice any change in process state transition. Traditionally processes are stopped with stop signal. But we have a better choise - [https://www.kernel.org/doc/Documentation/cgroup-v1/freezer-subsystem.txt a freezer cgroup].