[CRIU] Criu mod to restore files to state when checkpoint taken ...
Christopher Covington
cov at codeaurora.org
Thu Jan 8 08:22:03 PST 2015
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.
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
More information about the CRIU
mailing list