8
edits
Changes
no edit summary
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 ==