CGroups - Revision history

Kir: formatting/wording nits

2020-02-05T22:48:32Z

formatting/wording nits

Avagin: /* CGroups restoring strategy */

2020-02-05T18:13:06Z

CGroups restoring strategy

Radostin: Add --manage-cgroups ignore (commit 42e5c04)

2019-08-14T00:08:27Z

Add --manage-cgroups ignore (commit 42e5c04)

Radostin: /* CGroups that are visible by tasks */

2018-12-13T09:02:34Z

CGroups that are visible by tasks

Kir: /* CGroups restoring strategy */ proper formatting

2016-09-20T19:39:08Z

CGroups restoring strategy: proper formatting

Kir: /* Restoring into different CGroups */ proper formatting, and it also works on dump

2016-09-20T19:35:59Z

Restoring into different CGroups: proper formatting, and it also works on dump

Kir: /* Restoring into different CGroups */ rm <>

2016-09-20T19:33:59Z

Restoring into different CGroups: rm <>

Tycho Andersen at 18:16, 20 September 2016

2016-09-20T18:16:24Z

Cyrillos at 20:58, 29 July 2015

2015-07-29T20:58:48Z

Cyrillos at 20:58, 29 July 2015

2015-07-29T20:58:31Z

@@ Line 57: / Line 57: @@
 == External CGroup yard ==
-The option syntax is --cgroup-yard path.
+The option syntax is <code>--cgroup-yard path</code>.
-Instead of trying to mount cgroups in CRIU, provide a path to a directory with already created cgroup yard. Useful if you don't want to grant CAP_SYS_ADMIN to CRIU. For every cgroup mount there should be exactly one directory. If there is only one controller in this mount, the dir's name should be just the name of the controller. If there are multiple controllers comounted, the directory name should have them be separated by a comma.
+Instead of trying to mount cgroups in CRIU, provide a path to a directory with already created cgroup yard. Useful if you don't want to grant <code>CAP_SYS_ADMIN</code> to CRIU. For every cgroup mount there should be exactly one directory. If there is only one controller in this mount, the dir's name should be just the name of the controller. If there are multiple controllers co-mounted, the directory name should be a comma-separated list of controllers.
 [[Category:Under the hood]]

← Older revision		Revision as of 18:13, 5 February 2020
Line 55:		Line 55:

	By default, <code>soft</code> is assigned if <code>--manage-cgroups</code> option passed without an argument (i.e. the same as <code>--manage-cgroups=soft</code>).		By default, <code>soft</code> is assigned if <code>--manage-cgroups</code> option passed without an argument (i.e. the same as <code>--manage-cgroups=soft</code>).
		+
		+	== External CGroup yard ==
		+	The option syntax is --cgroup-yard path.
		+
		+	Instead of trying to mount cgroups in CRIU, provide a path to a directory with already created cgroup yard. Useful if you don't want to grant CAP_SYS_ADMIN to CRIU. For every cgroup mount there should be exactly one directory. If there is only one controller in this mount, the dir's name should be just the name of the controller. If there are multiple controllers comounted, the directory name should have them be separated by a comma.

	[[Category:Under the hood]]		[[Category:Under the hood]]

@@ Line 52: / Line 52: @@
 * <code>full</code>. Always restore all cgroups and their properties.
 * <code>strict</code>. Restore all cgroups and their properties from the scratch, requiring them to not present in the system.
 By default, <code>soft</code> is assigned if <code>--manage-cgroups</code> option passed without an argument (i.e. the same as <code>--manage-cgroups=soft</code>).
 [[Category:Under the hood]]

@@ Line 21: / Line 21: @@
 == CGroups that are visible by tasks ==
-Other than CGroups collected with tasks there can be other groups in which no tasks live. To pick up those CRIU gets the root set and saves all the CGroups tree starting from it. This information is stored in the <code>cgroup.controllers</code> image. In the same place CRIU saves the properties of CGroups -- these are values read from CGroup configuration files. Note -- since CRIU starts from root set and scans the directories tree, all the paths in this section are also subdirs of the root set's.
+Other than CGroups collected with tasks there can be other groups in which no tasks live. To pick up those CRIU gets the root set and saves all the CGroups tree starting from it. This information is stored in the <code>cgroup.controllers</code> image. In the same place CRIU saves the properties of CGroups (i.e. values read from CGroup configuration files). Note that since CRIU starts from root set and scans the directories tree, all the paths in this section are also subdirs of the root set's.
 In order to make CRIU handle this information on dump and restore one should specify the <code>--manage-cgroups</code> option.

@@ Line 45: / Line 45: @@
 When restoring cgroups CRIU may meet already existing cgroup controllers and as result it relies on user choice how to behave in such case: should it overwrite existing properties with values from the image or should ignore them? Or maybe it is unacceptable to modify any existing cgroup?
-To break a tie CRIU supports that named restore modes, which should be specified as an addition to <code>--manage-cgroups</code> option. Mode may be one of the following:
+To break a tie CRIU supports that named restore modes, which should be specified as an addition to <code>--manage-cgroups=''mode''</code> option. The <code>''mode''</code> argument may be one of the following:
-# <code>none</code>. Do not restore cgroup properties but require cgroup to pre-exist at the moment of restore procedure.
+* <code>none</code>. Do not restore cgroup properties but require cgroup to pre-exist at the moment of restore procedure.
-# <code>props</code>. Restore cgroup properties and require cgroup to pre-exist.
+* <code>props</code>. Restore cgroup properties and require cgroup to pre-exist.
-# <code>soft</code>. Restore cgroup properties if only cgroup has been created by *criu*, otherwise do not restore properies.
+* <code>soft</code>. Restore cgroup properties if only cgroup has been created by *criu*, otherwise do not restore properies.
-# <code>full</code>. Always restore all cgroups and their properties.
+* <code>full</code>. Always restore all cgroups and their properties.
-# <code>strict</code>. Restore all cgroups and their properties from the scratch, requiring them to not present in the system.
+* <code>strict</code>. Restore all cgroups and their properties from the scratch, requiring them to not present in the system.
-By default <code>soft</code> is assigned if <code>--manage-cgroups</code> option passed without argument (i.e. the same as <code>--manage-cgroups=soft</code>).
+By default, <code>soft</code> is assigned if <code>--manage-cgroups</code> option passed without an argument (i.e. the same as <code>--manage-cgroups=soft</code>).
 [[Category:Under the hood]]

@@ Line 39: / Line 39: @@
 == Restoring into different CGroups ==
-The option syntax is <code>--cgroup-root [''controller'':]/''path''</code> and it only makes sense on restore. Without this option CRIU would restore tasks and groups that live in the subtrees starting from the root task's dirs. When this option is given, the respective controllers' will get restoring starting from the give path instead.
+The option syntax is <code>--cgroup-root [''controller'':]/''path''</code>. Without this option, CRIU restores tasks and groups that live in the subtrees starting from the root task's dirs. When this option is given, the respective <code>''controller''</code>s are restored under the given <code>''path''</code>s instead.
 == CGroups restoring strategy ==

← Older revision		Revision as of 18:16, 20 September 2016
Line 24:		Line 24:

	In order to make CRIU handle this information on dump and restore one should specify the <code>--manage-cgroups</code> option.		In order to make CRIU handle this information on dump and restore one should specify the <code>--manage-cgroups</code> option.
		+
		+	== Dumping more cgroups than are visible ==
		+
		+	In some cases, it can be useful to dump a specific cgroup subtree, regardless of what cgroups the container's tasks are in. For example, systemd-based containers like Ubuntu 16.04 will put all of their tasks in one of <code>/init.scope</code>, <code>/system.slice/...</code>, or <code>/user.slice/...</code>. By default, then, CRIU's cgroup engine will not dump the root of the cgroup tree <code>/</code>. The problem is that systemd opens <code>/</code> as a directory FD and changes the permissions on it, resulting in errors like
		+
		+	<code>(00.361723) 1: Error (criu/files-reg.c:1487): File sys/fs/cgroup/systemd has bad mode 040755 (expect 040775)</code>
		+
		+	The solution is for the container engine to tell CRIU the root of the tree to start dumping at, via <code>--cgroup-root</code> on dump, so that these permissions are preserved when checkpointing the cgroup tree.

	== Mountpoints of "cgroup" file system ==		== Mountpoints of "cgroup" file system ==