<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 1:47 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On 06/21/2014 04:21 AM, Saied Kazemi wrote:<br>
> CRIU fails to restore a process running inside a Docker container with the error message:<br>
><br>
> (00.035110) Â Â Â 1: Error (cgroup.c:278): cg: Can't move into blkio//docker/2fda692b0fd31c20197b84b8ca5e172679dfaf9028c7322b7bb43acf061626cf/tasks (-1/-1)<br>
><br>
> This is because the container subdirectory (i.e., 64-character ID above) is not created under docker.<br>
><br>
> I applied the following quick patch as a workaround and was able to successfully restore and resume a process<br>
> running inside a Docker container. Â But the issue requires more study and changes as simply recreating the<br>
> directories on demand may not be enough.<br>
<br>
</div>Yes, the problem with cgroup FS tree is a bit deeper. Not only we should create the<br>
directories of cgroups tasks live in, but also create the sub-directories with no tasks<br>
e.g. to handle the case when a task does<br>
<br>
mkdir "cg/subcg"<br>
echo $pid > "cg/subcg/tasks"<br>
<br>
and we dump this app in between these two calls.<br></blockquote><div><br></div><div>I did sone experiments and below is what I found.</div><div><br></div><div>As long as the cgroup is not deleted, we should be ok because the process will enter the cgroup after restore when echo is done. Â Isn't this like the case where "cg/subcg" is just a normal directory and we're trying to create a file in it? Â If the normal directory is deleted after dump and before restore, the echo will fail.</div>
<div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Other than this we probably should take care of the configuration of these subcgroups,<br>
e.g. mem.* files in memsg and other stuff.<br></blockquote><div><br></div><div>The configuration information is not lost after dump as long as the cgroups (or subcgroups) are not deleted, so restore shouldn't have to worry about it. Â It's just like the case above. Â Am I missing something obvious here?</div>
<div>Â <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
And the third thing -- there may be cgroup FS mountpoints inside the mount namespace<br>
we dump. These should be dumped as well.<br></blockquote><div><br></div><div>Yes, I created a cgroup mountpoint inside my mount namespace (at /cgroup_dir) which caused criu dump to fail with the error message:</div><div>
<br></div><div>Â Â Error (mount.c:414): FS mnt ./cgroup_dir dev 0x22 root / unsupported id 4f</div><div><br></div><div>Fortunately, Docker containers I've been using so far do not create such internal cgroup mountpoints. Â Also, I don't think LXC does it either. Â So support for this case can have low priority.</div>
<div><br></div><div>At this point, we need to converge on a solution for creating cgroups subdirs. Â I am still using the patch that I sent you before because I tried the other patch I saw in the mailing list this morning but it didn't work.</div>
<div><br></div><div>--Saied</div><div><br></div></div></div></div>