[CRIU] implementing some kind of --leave-frozen option for c/r in CRIU

[Tycho Andersen]

On Mon, May 16, 2016 at 04:00:41PM +0300, Batalov Eugene wrote:
> Hello.
> 
> The idea of Pavel to reuse part of "restore: restore freezer cgroup state"
> patch looks good and simple.
> 
> About networking unlock. Yes. There is a work in progress on new criu gc
> command.
> You can find patch commit here:
> https://github.com/AuthenticEshkinKot/criu/commit/2ab52fec7a05f9792c871709758d14137fe9f379
> 
> The main problem with it is the fact that network unlock and link remaps
> cleanup logic
> is coupled with logic of criu restore command. And criu restore logic is
> not trivial.
> 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).

Hm. Actually I wonder if this approach will work entirely.
gc_prepare_namespace() just calls prepare_pstree() and
prepare_mnt_ns(), which won't attach to the namespaces of the dumped
(or restored) tasks, but instead creates entirely new namespaces and
removes the files from there. It also doesn't (I don't think) setns to
the right place when it does network_unlock, because nothing sets up
the right network namespace.

It seems like this mode also needs a -t option to attach to the right
task that it should clean up, as well as the images directory. Does
that make sense?

Tycho

> GRIU gc both able print what's left in the system after dump (iptables,
> link remaps) and to cleanup this stuff too.
> 
> 
> 2016-05-16 15:31 GMT+03:00 Pavel Emelyanov <xemul at virtuozzo.com>:
> 
> > On 05/10/2016 08:04 PM, Tycho Andersen wrote:
> > > Hi guys,
> > >
> > > I'm looking at implementing some kind of --leave-frozen option in
> > > CRIU, so that we can have a basic UX in LXD where we can wait for the
> > > restore to be successful before we kill the checkpointed container. I
> > > know p.haul does this by just using a callback, but it would be sort
> > > of painful to absorb just the callback part without doing a lot of
> > > extra engineering. We'll get LXD using p.haul someday, though :)
> > >
> > > The actual --leave-frozen patch is not so bad (see attached), but I'm
> > > not sure what to do about the network locking/unlocking bits.
> >
> > There was a patch 8b04551c (restore: restore freezer cgroup state) in 2.0
> > that turned cgroup into whatever state it was before dump. Can it be fixed
> > to make '--leave-frozen' alter the behavior of
> > add_freezer_state_for_restore()
> > and set it to 'frozen' always?
> >
> > > It seems like it is always safe to do the bits in
> > > cpt_unlock_tcp_connections() since that's just disabling tcp repair
> > > mode, but all of the iptables rules seem necessary in order to keep
> > > the network locked.
> > >
> > > So my question is: is there a nice way we can "tag" these rules so
> > > that something can come by and delete them later? I was thinking about
> > > having criu add a comment (via -m comment --comment "CRIU-LOCK-RULE")
> > > to each rule it adds, but I'm not sure if there's a better way, or if
> > > I've missed something entirely.
> >
> > Yes, there's an issue #45 -- show what's left in the system after dump.
> > Iptables
> > rules are in the list :) I know that some gentlemen (Cc) from
> > Saint-Petersburg were
> > interested in implementing it in form of 'criu gc' action, so probably
> > tuning this
> > option to support '--show-only' would help you?
> >
> > > Thanks!
> > >
> > > Tycho
> > >
> > >
> > >
> > > _______________________________________________
> > > CRIU mailing list
> > > CRIU at openvz.org
> > > https://lists.openvz.org/mailman/listinfo/criu
> > >
> >
> >
> 
> 
> -- 
> Best regards,
> Eugene Batalov.