[CRIU] Building CRIU from Head

[Adrian Reber]

On Tue, Feb 16, 2016 at 04:46:02PM -0700, Tycho Andersen wrote:
> 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.

I would also be interested in a 'criu check' version which does not error
out with:

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:686): Dirty tracking is OFF. Memory snapshot will not work.

return value 1

I always get the last warning which is not a problem for me. I used to
get (that's with criu 1.6.1):

Warn  (mem.c:52): Can't reset 16206's dirty memory tracker (22)
Warn  (cr-check.c:581): Dirty tracking is OFF. Memory snapshot will not work.
Looks good.

return value 0

It would be nice for the check to not return an error as C/R is still
working (without seccomp of course).

		Adrian

> > 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