Pre-created cpuset cgroup with not configured .cpus/.mems causes restore to fail #16
Comments
|
Forgot to say, host of checkpointed container os |
Here's the error. The file /tmp/ib927lru.cr.1 exists, while shouldn't. Have you modified the filesystem somehow before restore? |
|
What you mean if I have modified the fs before? I don't think so.. I only have applied the patches tha referred to the criu/docker page.. this file shouldn't have been there? Do you think that if i remove it, it will be ok? Thanks for the reply.. |
|
I mean -- what did you do to get the filesystem of your container on the destination node? The file I mentioned (ib927lru.cr.1.ghost) is created by CRIU upon restore with unique name, according to logs this file is created only once, but it's already there. I wonder how this could happen? And yes, if you remove this file this particular error will go away. |
|
@xemul thanks again.. You were right about this particular file. I run the docker restore command multiple times so probably the file was there from a previous execution on the same container. The right log file is the bellow: |
|
OK, now we have ENOSPC from cpuset.tasks write. This usually happens when the cpuset.cpus or .mems is not set. Can you check the restore logs for "Restored cgroup property value..." message? |
|
I was not able to find the restored cgroup property value, but I may not be able to locate it. I uploaded the entire log file here https://gist.github.com/klesgidis/06eff8fc2eeb3b9b0dec for reference. |
|
Looks like we forgot to set the manage-cgroup option to restore a
|
|
Probably yes :) Asking for @boucher help again. |
|
@avagin In libcontainer? It seems like we're setting it: |
|
@boucher you are right. So the question is still open. |
|
I think I've found it :) @cyrillos , look at the prepare_cgroup_dirs(). If the faccessat() call succeeds (directory exists) we don't call for restore_special_cpuset_props(). |
|
I'll take a look, thanks |
|
So, this kind of behavior (restoring cpuset props if only controller didn't exist) came from commit 003aed3 as far as I can say. Thus to figure out if it is indeed a reason one should setup --manage-cgroups=full instead of soft mode which is by-default. |
|
In commit 46e8aee we have added appropriate modes for RPC calls. |
|
Hi Cyrill, On Wed, Aug 12, 2015 at 11:28:25AM -0700, Cyrill Gorcunov wrote:
I think the discussion is here: http://lists.openvz.org/pipermail/criu/2014-October/017084.html Basically, if criu didn't create the cgroup, we try not to to touch Tycho |
|
Need to refresh memory ;) Thanks I'll try to read it tomorrow. |
|
I think we just decided that if cgroup exists it should be properly configured. Right now it seems not to be the case :\ And the question from me -- if we take existing cgroup and this cgroup doesn't have cpuset.cpus/.mems set, where does this cgroup came from? Why created it and how? |
xemul
changed the title
|
opencontainers/runc#253 |
|
A friendly reminder that this issue had no activity for 30 days. |
Hi! I 'm trying to restore a docker MySQL container to another host. So I checkpointed it, moved the dump files to another PC, created a new "identical" container (didn't run it) and executed
The results
The restore log
Any help? Thank you..
The text was updated successfully, but these errors were encountered: