<div dir="ltr">Hello.<div><br></div><div>The idea of Pavel to reuse part of "<span style="font-size:12.8px">restore: restore freezer cgroup state</span>" patch looks good and simple.</div><div><br></div><div>About networking unlock. Yes. There is a work in progress on new criu gc command.</div><div>You can find patch commit here: <a href="https://github.com/AuthenticEshkinKot/criu/commit/2ab52fec7a05f9792c871709758d14137fe9f379">https://github.com/AuthenticEshkinKot/criu/commit/2ab52fec7a05f9792c871709758d14137fe9f379</a></div><div><br></div><div>The main problem with it is the fact that network unlock and link remaps cleanup logic</div><div>is coupled with logic of criu restore command. And criu restore logic is not trivial.</div><div>So we're trying to carefully reduce the amount of code in CRIU gc. We need to reuse CRIU restore command code and need not to introduce ugly hacks and excessive CRIU restore code dependencies (this dependence would limit CRIU restore code changes at the same time).</div><div><br></div><div>GRIU gc both able print what's left in the system after dump (iptables, link remaps) and to cleanup this stuff too.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-05-16 15:31 GMT+03:00 Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@virtuozzo.com" target="_blank">xemul@virtuozzo.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05/10/2016 08:04 PM, Tycho Andersen wrote:<br>
> Hi guys,<br>
><br>
> I'm looking at implementing some kind of --leave-frozen option in<br>
> CRIU, so that we can have a basic UX in LXD where we can wait for the<br>
> restore to be successful before we kill the checkpointed container. I<br>
> know p.haul does this by just using a callback, but it would be sort<br>
> of painful to absorb just the callback part without doing a lot of<br>
> extra engineering. We'll get LXD using p.haul someday, though :)<br>
><br>
> The actual --leave-frozen patch is not so bad (see attached), but I'm<br>
> not sure what to do about the network locking/unlocking bits.<br>
<br>
There was a patch 8b04551c (restore: restore freezer cgroup state) in 2.0<br>
that turned cgroup into whatever state it was before dump. Can it be fixed<br>
to make '--leave-frozen' alter the behavior of add_freezer_state_for_restore()<br>
and set it to 'frozen' always?<br>
<br>
> It seems like it is always safe to do the bits in<br>
> cpt_unlock_tcp_connections() since that's just disabling tcp repair<br>
> mode, but all of the iptables rules seem necessary in order to keep<br>
> the network locked.<br>
><br>
> So my question is: is there a nice way we can "tag" these rules so<br>
> that something can come by and delete them later? I was thinking about<br>
> having criu add a comment (via -m comment --comment "CRIU-LOCK-RULE")<br>
> to each rule it adds, but I'm not sure if there's a better way, or if<br>
> I've missed something entirely.<br>
<br>
Yes, there's an issue #45 -- show what's left in the system after dump. Iptables<br>
rules are in the list :) I know that some gentlemen (Cc) from Saint-Petersburg were<br>
interested in implementing it in form of 'criu gc' action, so probably tuning this<br>
option to support '--show-only' would help you?<br>
<br>
> Thanks!<br>
><br>
> Tycho<br>
><br>
><br>
><br>
> _______________________________________________<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" rel="noreferrer" target="_blank">https://lists.openvz.org/mailman/listinfo/criu</a><br>
><br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Best regards,<br>Eugene Batalov.</div>
</div>