[CRIU] Building CRIU from Head

[Saied Kazemi]

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

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160216/fc786c58/attachment.html>