[CRIU] [PATCH] Make restored processes inherit file descriptors from criu

[Saied Kazemi]

On Tue, Dec 2, 2014 at 11:09 AM, Pavel Emelyanov <xemul at parallels.com> wrote:
>
>> I understand the problem you're explaining with the state of the
>> struct file between the file descriptor table and the inode but
>> because of the following reasons we can't address this issue with a
>> command line option like $pid$fd:$fd2 or anything else for that
>> matter.
>>
>> 1. The root/init process may have passed down its descriptor to a
>> distant descendant, so there is no way to know which $pid to specify.
>>
>> 2. Whatever process using the descriptor may have moved its fd, so
>> there is no way to know which $fd to specify.
>
> Yes, you're right. The $pid.$fd is bad pointer to the file we want
> to replace.
>
> And AFAIU my other proposal of using the ID from image doesn't work
> well too -- criu caller might not know this ID.
>
> Your proposal is good because user does know the object ID. For pipes
> it's the pipe_id value (got by stat()-ing its pipe end) and for the
> log file it's its name (just known :) ).
>
>> As an example, consider the following simple shell script in which
>> $</bin/sh-pid>:$fd[1] becomes $</bin/dash-pid>:$fd[3].
>>
>> $ /bin/sh -c 'exec 3>&1; exec 1>&-; /bin/dash -c "i=0; while true; do
>> echo \$i >&3; i=\$(expr \$i + 1); sleep 1; done"'
>>
>> As you said, it's best to introduce --inherit-fd as an experimental
>> "use it at your own risk" command line option that is suitable for
>> specific use cases (most notably pipes and log files).  We can even
>> add a --experimental command line option that should be specified to
>> use --inherit-fd (and also other experimental options, if any).  This
>> way the users will definitely realize that the API is experimental and
>> may change or disappear.
>
> Let's do the thing -- we add this option the way you propose, but
> till 1.5 release (planned on the 2nd of March) will continue thinking
> on better way of addressing the file, rather than the inode. Or some way
> to untie them on restore. I'm really afraid, that inheriting one files
> into many will come back to bite us later :)

Sounds good.  You should have received the patches that I just sent.
Now it's an option only for restore with absolutely minimal changes to
core criu functionality.

In a separate email, I will send a test program written in C to
demonstrate how to inherit a pipe.  I will also send instructions for
the HOWTO page.

> Thanks,
> Pavel

--Saied