[CRIU] Building CRIU from Head

[Saied Kazemi]

ThanksTycho.  Option name --no-seccomp sounds good.  The patch would be
great as we really want to use CRIU from head but cannot!

--Saied


On Tue, Feb 16, 2016 at 3:46 PM, Tycho Andersen <
tycho.andersen at canonical.com> 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.
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160216/e3eb094b/attachment.html>