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

[Pavel Emelyanov]

> 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 :)

Thanks,
Pavel