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