[CRIU] Building CRIU from Head

[Tycho Andersen]

On Tue, Feb 16, 2016 at 10:28:14AM -0800, Saied Kazemi wrote:
> + CRIU mailing list
> 
> Sorry for the delay due to Presidents Day long weekend.  There are two
> issues, immediate and not-so-immediate.
> 
> The immediate issue is that we can no longer use CRIU built from head
> unless running a very recent kernel (can't ask people to upgrade their
> kernels).  What can be done about this?  Can we add a flag to CRIU to
> ignore seccomp stuff?

Sure, we can do that. Of course then it won't be seccomp contained on
restore, but I guess that's ok for you :)

I can send a patch if we can agree on the name of the option. I'll
propose --no-seccomp.

Tycho

> The not-so-immediate issue is the check modes.  The three modes you've
> suggested sound OK but how would CRIU work if some of them fail?  In the
> past, as long as --ms passed, CRIU would work.
> 
> --Saied
> 
> 
> On Fri, Feb 12, 2016 at 6:16 AM, Pavel Emelyanov <xemul at virtuozzo.com>
> wrote:
> 
> > On 02/11/2016 10:54 PM, Saied Kazemi wrote:
> > > Hi Pavel,
> > >
> > > Since Madhu mentioned that he had an issue making his C/R set up work
> > end to end, I wanted to write instructions on how to do this and provide an
> > example.  I started off with a freshly built VM instance running Ubuntu
> > 15.04 (Vivid, 3.19 kernel), installed gcc, make, git, and package CRIU
> > needs.  Then I cloned CRIU:
> > >
> > > $ git clone https://github.com/xemul/criu.git && cd criu && make
> > > $ sudo make install
> > > $ sudo criu check --ms
> > >
> > > In the past, if check fails it's been due to linux-image-extra.
> > >
> > > $ sudo apt-get install linux-image-extra-$(uname -r)
> > >
> > > But this time, I am getting seccomp errors.
> > >
> > > $ sudo criu check --ms
> > > Error (cr-check.c:629): Kernel doesn't support PTRACE_O_SUSPEND_SECCOMP
> > > Error (cr-check.c:673): Dumping seccomp filters not supported:
> > Input/output error
> > > Warn  (cr-check.c:789): fdinfo doesn't contain the lock field
> > >
> > > Does this mean that anyone building CRIU from head needs to run a very
> > recent kernel?
> > > If so, this can significantly limit CRIU usage as building a new kernel
> > and installing
> > > it is not a trivial task.  Is there a way to tell CRIU ignore seccom?
> >
> > Ah, that's due to 2f41a8a8 (or fe76ccde). Tycho had his patches accepted
> > and
> > released so we dropped the --ms check.
> >
> > My impression on this is that we've put too much meaning on the --ms
> > option.
> > Originally it was the option that forced criu to check only for features
> > that
> > had hit the upstream. Now we have another set of ... things -- the features
> > whose presence in the kernel doesn't necessarily mean dump would fail, but
> > rather _may_ fail to dump (or restore) something. E.g. -- soft dirty
> > tracker,
> > tun support or this seccomp thing.
> >
> > Plus we have per-feature checks, but that's another story.
> >
> > I would suggest that we make 3 explicit check modes (apart from per-check
> > ones) -- check for minimal support, check for full features support and
> > check
> > for experimental features support. But this should better be discussed on
> > the mailing list. What do you think?
> >
> > -- Pavel
> >

> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu