<div dir="ltr">ThanksTycho. Option name --no-seccomp sounds good. The patch would be great as we really want to use CRIU from head but cannot!<div><br></div><div>--Saied</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 16, 2016 at 3:46 PM, Tycho Andersen <span dir="ltr"><<a href="mailto:tycho.andersen@canonical.com" target="_blank">tycho.andersen@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Tue, Feb 16, 2016 at 10:28:14AM -0800, Saied Kazemi wrote:<br>
> + CRIU mailing list<br>
><br>
> Sorry for the delay due to Presidents Day long weekend. There are two<br>
> issues, immediate and not-so-immediate.<br>
><br>
> The immediate issue is that we can no longer use CRIU built from head<br>
> unless running a very recent kernel (can't ask people to upgrade their<br>
> kernels). What can be done about this? Can we add a flag to CRIU to<br>
> ignore seccomp stuff?<br>
<br>
</span>Sure, we can do that. Of course then it won't be seccomp contained on<br>
restore, but I guess that's ok for you :)<br>
<br>
I can send a patch if we can agree on the name of the option. I'll<br>
propose --no-seccomp.<br>
<br>
Tycho<br>
<div><div class="h5"><br>
> The not-so-immediate issue is the check modes. The three modes you've<br>
> suggested sound OK but how would CRIU work if some of them fail? In the<br>
> past, as long as --ms passed, CRIU would work.<br>
><br>
> --Saied<br>
><br>
><br>
> On Fri, Feb 12, 2016 at 6:16 AM, Pavel Emelyanov <<a href="mailto:xemul@virtuozzo.com">xemul@virtuozzo.com</a>><br>
> wrote:<br>
><br>
> > On 02/11/2016 10:54 PM, Saied Kazemi wrote:<br>
> > > Hi Pavel,<br>
> > ><br>
> > > Since Madhu mentioned that he had an issue making his C/R set up work<br>
> > end to end, I wanted to write instructions on how to do this and provide an<br>
> > example. I started off with a freshly built VM instance running Ubuntu<br>
> > 15.04 (Vivid, 3.19 kernel), installed gcc, make, git, and package CRIU<br>
> > needs. Then I cloned CRIU:<br>
> > ><br>
> > > $ git clone <a href="https://github.com/xemul/criu.git" rel="noreferrer" target="_blank">https://github.com/xemul/criu.git</a> && cd criu && make<br>
> > > $ sudo make install<br>
> > > $ sudo criu check --ms<br>
> > ><br>
> > > In the past, if check fails it's been due to linux-image-extra.<br>
> > ><br>
> > > $ sudo apt-get install linux-image-extra-$(uname -r)<br>
> > ><br>
> > > But this time, I am getting seccomp errors.<br>
> > ><br>
> > > $ sudo criu check --ms<br>
> > > Error (cr-check.c:629): Kernel doesn't support PTRACE_O_SUSPEND_SECCOMP<br>
> > > Error (cr-check.c:673): Dumping seccomp filters not supported:<br>
> > Input/output error<br>
> > > Warn (cr-check.c:789): fdinfo doesn't contain the lock field<br>
> > ><br>
> > > Does this mean that anyone building CRIU from head needs to run a very<br>
> > recent kernel?<br>
> > > If so, this can significantly limit CRIU usage as building a new kernel<br>
> > and installing<br>
> > > it is not a trivial task. Is there a way to tell CRIU ignore seccom?<br>
> ><br>
> > Ah, that's due to 2f41a8a8 (or fe76ccde). Tycho had his patches accepted<br>
> > and<br>
> > released so we dropped the --ms check.<br>
> ><br>
> > My impression on this is that we've put too much meaning on the --ms<br>
> > option.<br>
> > Originally it was the option that forced criu to check only for features<br>
> > that<br>
> > had hit the upstream. Now we have another set of ... things -- the features<br>
> > whose presence in the kernel doesn't necessarily mean dump would fail, but<br>
> > rather _may_ fail to dump (or restore) something. E.g. -- soft dirty<br>
> > tracker,<br>
> > tun support or this seccomp thing.<br>
> ><br>
> > Plus we have per-feature checks, but that's another story.<br>
> ><br>
> > I would suggest that we make 3 explicit check modes (apart from per-check<br>
> > ones) -- check for minimal support, check for full features support and<br>
> > check<br>
> > for experimental features support. But this should better be discussed on<br>
> > the mailing list. What do you think?<br>
> ><br>
> > -- Pavel<br>
> ><br>
<br>
</div></div>> _______________________________________________<br>
> CRIU mailing list<br>
> <a href="mailto:CRIU@openvz.org">CRIU@openvz.org</a><br>
> <a href="https://lists.openvz.org/mailman/listinfo/criu" rel="noreferrer" target="_blank">https://lists.openvz.org/mailman/listinfo/criu</a><br>
<br>
</blockquote></div><br></div>