<div dir="ltr"><div>+ CRIU mailing list</div><div><br></div>Sorry for the delay due to Presidents Day long weekend. There are two issues, immediate and not-so-immediate.<div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>--Saied</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 12, 2016 at 6:16 AM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@virtuozzo.com" target="_blank">xemul@virtuozzo.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 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 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:<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: 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 recent kernel?<br>
> If so, this can significantly limit CRIU usage as building a new kernel and installing<br>
> it is not a trivial task. Is there a way to tell CRIU ignore seccom?<br>
<br>
</span>Ah, that's due to 2f41a8a8 (or fe76ccde). Tycho had his patches accepted 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 option.<br>
Originally it was the option that forced criu to check only for features 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 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 check<br>
for experimental features support. But this should better be discussed on<br>
the mailing list. What do you think?<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Pavel<br>
</font></span></blockquote></div><br></div>