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

[Pavel Emelyanov]

On 01/07/2015 10:19 PM, 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.

What if we make CRIU talk to the *-diag subsystems with some simple
and short requests? If the *diag is built in, then it's there, if it's
module, kernel would auto-load them as it did before.

Thanks,
Pavel