<div dir="ltr">Yes, in practice it would be the responsibility of an "agent" (Docker, LXC, migration agent, etc.) to create the cgroups before attempting to restore the process. In fact if restore is done on a different machine, the cgroups properties of the source machine may not even apply on the destination machine.<div>
<br></div><div>That said, I think we can/should do without --no-restore-cgroup option because the cgroups restore logic in CRIU should detect that everything is already setup and there is no need for it to do anything (effectively it becomes a noop).</div>
<div><br></div><div>In short, CRIU usage will be easier with less options.</div><div><br></div><div>--Saied</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 4, 2014 at 8:08 AM, Cyrill Gorcunov <span dir="ltr"><<a href="mailto:gorcunov@gmail.com" target="_blank">gorcunov@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On Mon, Aug 04, 2014 at 09:59:01AM -0500, Tycho Andersen wrote:<br>
><br>
> Users may already be restoring their own cgroups; now that criu does this,<br>
> those users may want to turn criu's version off until/unless they migrate.<br>
<br>
</div>Thanks for changelog! I'm not really following the reallife scenario though.<br>
Up to Pavel the rest.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
CRIU mailing list<br>
<a href="mailto:CRIU@openvz.org">CRIU@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/criu" target="_blank">https://lists.openvz.org/mailman/listinfo/criu</a><br>
</div></div></blockquote></div><br></div>