<div dir="ltr"><div><div>Hi, Cyrill<br></div><div>To provide more information about this patch.<br><br></div>From the cgroup.c, I see that if the restoring stratgy is full, it will always restore all the cgroup properties, which includes /sys/fs/cgroup/cpusets.cpu. As that file is not write-able by criu (i.e., echo &quot;1024&quot; &gt; /sys/fs/cgroup/cpusets.cpu fails), it will cause problem.<br><br></div><div>In contrast, when restoring with &quot;soft&quot; mode, the e-&gt;n_properties is zero so that restore_cgroup_prop() is not called. <br><br></div>- Hui<br><div><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 6:00 PM, Cyrill Gorcunov <span dir="ltr">&lt;<a href="mailto:gorcunov@gmail.com" target="_blank">gorcunov@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Aug 12, 2015 at 05:37:35PM -0400, Hui Kang wrote:<br>
&gt;<br>
&gt;      Could you please explain how we end up having empty dir_name here?<br>
&gt;<br>
&gt;    This happens when restoring a process with cgroup using<br>
&gt;    --manage-cgroup=full. <br>
&gt;    To reproduce this error<br>
&gt;    1. start a process<br>
&gt;    2. mkdir /sys/fs/cgroups/cpusets/foo<br>
&gt;    3. echo PID &gt; /sys/fs/cgroups/cpusets/foo/tasks<br>
&gt;    4. checkpoint the process<br>
&gt;    5. rmdir /sys/fs/cgroups/cpusets/foo or copy the checkedpoint images to a<br>
&gt;    different host<br>
&gt;    5. /root/criu/criu restore --log-file ./restore.log -vvvv -j <br>
&gt;    --manage-cgroup=full<br>
<br>
</span>Hmm. Thanks for info! Need to think...<br>
</blockquote></div><br></div></div></div></div></div></div></div>