[CRIU] Criu mod to restore files to state when checkpoint taken ...

[Tycho Andersen]

On Thu, Jan 08, 2015 at 11:22:03AM -0500, Christopher Covington wrote:
> On 01/08/2015 09:57 AM, Tycho Andersen wrote:
> > Hi Chris,
> > 
> > On Wed, Jan 07, 2015 at 02:19:32PM -0500, Christopher Covington wrote:
> >> On 01/03/2015 09:36 AM, Tycho Andersen wrote:
> >>> On Fri, Jan 02, 2015 at 01:22:15PM -0500, Christopher Covington wrote:
> >>>> Hi Pavel,
> >>>>
> >>>> On 12/31/2014 08:50 AM, Pavel Emelyanov wrote:
> >>>>> On 12/31/2014 03:53 PM, "Mark O'Neill" wrote:
> >>>>
> >>>>>> 3. The required kernel functions (described on Criu website) must be
> >>>>>> added as modules (-=m) and not hardwired into kernel (=y) in Linux
> >>>>>> config file.
> >>>>>
> >>>>> This is strange. What problems have you seen with all-in kernel?
> >>>>
> >>>> At least for me, commit 2b5d06817f1bb2b28eec50b6705b1584435e580b introduced
> >>>> the following, which is actually spurious:
> >>>>
> >>>> (00.098217) Error (util.c:576): exited, status=1
> >>>> (00.164971) Error (util.c:576): exited, status=1
> >>>> (00.216945) Error (util.c:576): exited, status=1
> >>>> (00.296716) Error (util.c:576): exited, status=1
> >>>> (00.368518) Error (util.c:576): exited, status=1
> >>>>
> >>>> I originally proposed [1] a somewhat complex change of probing
> >>>> /proc/config.gz, but I think a quick and actually more general (as it doesn't
> >>>> require /proc/config.gz which is itself a configuration option) fix is to pass
> >>>> an fd to /dev/null into the cr_system() call.
> >>>
> >>> Yes, the /dev/null trick seems a little nicer. Let me know if you want
> >>> me to send a patch; I haven't had much time for criu recently, but I'm
> >>> happy to fix the mess I created :)
> >>
> >> Unfortunately, my instance of that change doesn't actually work. Only the
> >> forked child uses the file descriptors passed as arguments to cr_system() in
> >> util.c. The error handling logic of the parent uses pr_err, which is a macro
> >> around print_on_level and uses the log fd.
> > 
> > Just looking into this a bit more, it looks like more recent versions
> > of modprobe are smart enough to look at the statically built modules
> > and exit 0 if the module was built statically. My modprobe --version
> > shows:
> > 
> > $ modprobe --version
> > kmod version 18
> > 
> > I'm not very familiar with how all this works, maybe it is a fairly
> > recent change?
> >
> > Also, I don't have a /proc/config.gz, so even if we parsed that, since
> > it doesn't exist on all systems we may still get spurious errors.
> 
> I discovered yesterday that with busybox modprobe if I create an empty
> /lib/modules/$kernel_version directory, it'll return 0 even when the module is
> not found, which resolves the issue for me.

Glad to hear it. I suppose we could test for that directory and only
do the modprobe commands if it exists? Seems like a modprobe bug,
though...

Tycho

> Chris
> 
> -- 
> Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project