[CRIU] Problem in Seizing Open File Descriptors?

[Saied Kazemi]

On Tue, Jul 15, 2014 at 8:08 AM, Pavel Emelyanov <xemul at parallels.com>
wrote:

> On 07/15/2014 06:49 PM, Pavel Emelyanov wrote:
> > On 07/15/2014 06:34 PM, Saied Kazemi wrote:
> >> Thanks for the quick feedback.  I am using CRIU 1.3-rc2 (at commit
> e1b56c8fa) with Docker version
> >> 1.1.0 on Ubuntu 14.04 which does not provide mnt_id in
> /proc/pid/fdinfo/fd files.
> >
> > That can be a problem.
> >
> >> I will look into Docker source today.  Assuming that it does open
> /dev/null before moving into the
> >> namespaces, can CRIU handle it?
> >
> > It should, but without this field this would fail just the
> > way you observe with Docker :)
>
> After refreshing my memory and talking to Andrey (who wrote this code) the
> answer is -- no. When we have multiple mount namespaces files opened from
> outside are not dumped.
>

Is this because this case cannot be technically supported, or is it because
it has been a marginal case so far?



> For /dev/null you could consider using the --evasive-devices option. It
> will
> ask criu to dump the device's path in whichever location it's found. Not
> sure how would this affect Docker though.
>

The good news is that using --evasive-devices, it's possible to dump and
restore the process.  But, as you said, I am not sure yet how this would
affect Docker.  Will look into it.


> If you could confirm that on
> > the kernel with mnt_id in fdinfo it works, that would be
> > great. Meanwhile, I will try to make a test for this.
>

Will have to find a kernel with mnt_id support and repeat the tests.  This
may take a while.

Thanks,

--Saied
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20140715/ab0d18c7/attachment.html>