Changes

== CGroups that are visible by tasks ==

== 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.

In order to make CRIU handle this information on dump and restore one should specify the <code>--manage-cgroups</code> option.

== Restoring into different CGroups ==

== 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 ==

== CGroups restoring strategy ==

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?

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.

* <code>ignore</code>. Don't deal with cgroups and pretend that they don't exist.

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>).

 

 

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]]

[[Category:Under the hood]]