[CRIU] Android port

[CRIU criu]

lookup_nsid_by_mnt_id() fails for fd = 0
(00.314250) Error (files-reg.c:817): Unable to look up the 10 mount

(00.311795) 1915 fdinfo 0: pos: 0x               0 flags:           400002/0

Output from lsof | grep 1915
1915     u0_a37    *0*       ???                ???       ???        ???*
/dev/null*
1915     u0_a37   * 1*       ???                ???       ???        ???*
/dev/null*
1915     u0_a37    *2*       ???                ???       ???        ???*
/dev/null*

# cat /proc/1915/fdinfo/0
pos:    0
flags:    0400002
mnt_id:    10


However, I don't see mnt_id = 0xa (10) from mountinfo. Am I missing
something? Any idea where to look for this?


(00.043094)     type rootfs source rootfs mnt_id 0x19 s_dev 0x2 / @ ./
flags 0x1 options size=256340k,nr_inodes=64085
(00.043398)     type tmpfs source tmpfs mnt_id 0x1a s_dev 0xb / @ ./dev
flags 0x200002 options mode=755
(00.044501)     type devpts source devpts mnt_id 0x1b s_dev 0xa / @
./dev/pts flags 0x200000 options mode=600,ptmxmode=000
(00.045000)     type cgroup source none mnt_id 0x1c s_dev 0xf / @
./dev/memcg flags 0x200000 options memory
(00.045162)     type cgroup source none mnt_id 0x1d s_dev 0x12 / @
./dev/cpuctl flags 0x200000 options cpu
(00.045340)     type proc source proc mnt_id 0x1e s_dev 0x4 / @ ./proc
flags 0x200000 options
(00.045488)     type sysfs source sysfs mnt_id 0x1f s_dev 0xc / @ ./sys
flags 0x200000 options
(00.045699)     type debugfs source debugfs mnt_id 0x20 s_dev 0x6 / @
./sys/kernel/debug flags 0x200000 options
(00.045871)     type tmpfs source none mnt_id 0x21 s_dev 0xe / @
./sys/fs/cgroup flags 0x200000 options mode=750,gid=1000
(00.046066)     type cgroup source none mnt_id 0x22 s_dev 0xf / @
./sys/fs/cgroup/memory flags 0x200000 options memory
(00.046216)     type cgroup source none mnt_id 0x23 s_dev 0xd / @ ./acct
flags 0x200000 options cpuacct
(00.046418)     type tmpfs source tmpfs mnt_id 0x24 s_dev 0x10 / @
./mnt/asec flags 0x200000 options mode=755,gid=1000
(00.046616)     type tmpfs source tmpfs mnt_id 0x25 s_dev 0x11 / @
./mnt/obb flags 0x200000 options mode=755,gid=1000
(00.046794)     type ext4 source /dev/block/mtdblock0 mnt_id 0x26 s_dev
0x1f00000 / @ ./system flags 0x200001 options data=ordered
(00.046980)     type ext4 source /dev/block/mtdblock1 mnt_id 0x27 s_dev
0x1f00001 / @ ./data flags 0x406 options data=ordered
(00.047146)     type ext4 source /dev/block/mtdblock2 mnt_id 0x28 s_dev
0x1f00002 / @ ./cache flags 0x406 options data=ordered

On Thu, Jun 4, 2015 at 2:11 PM, Pavel Emelyanov <xemul at parallels.com> wrote:

> On 06/04/2015 11:46 PM, CRIU criu wrote:
> > On Thu, Jun 4, 2015 at 1:23 PM, Pavel Emelyanov <xemul at parallels.com
> <mailto:xemul at parallels.com>> wrote:
> >
> >     On 06/04/2015 05:35 PM, CRIU criu wrote:
> >     > Can CRIU be used to checkpoint/restore a single process and not a
> process tree?
> >
> >     Without a patch -- no, it always scans for the process subtree
> starting from the
> >     pid given.
> >
> >
> > Is there a patch already to do this?
>
> Well, nope :) We used to have the ability to dump and restore a single
> process with
> CRIU, but removed one way before v1.0 was released.
>
> >     > I keep hitting this error message:
> >     >
> >     >     if (item->sid == 0) {
> >     >
> >     >         pr_err("A session leader of %d(%d) is outside of its pid
> namespace\n",
> >     >
> >     >             item->pid.real, item->pid.virt);
> >     >
> >     >         goto err_cure;
> >     >
> >     >     }
> >
> >     But it's not about dumping a single task or a subtree, it's about
> the resources
> >     leaking outside of what you dump :)
> >
> >
> > I agree. However, an Android process behaves very differently from a
> regular linux process
> > - some of the resources are released when a process goes in the
> background so we don't have
> > to dump everything because released resources will be reacquired upon
> resume (restore) when
> > brought into foreground again. That means the way we resume will change
> for Android. I will
> > fix this as I go along.
>
> I see. Well, if there's a case to relax some restrictions CRIU impose on
> the linkage of
> resources tasks have, then the patch would be welcome :)
>
> > I also see "Uncollected sockets! Will probably fail later." error
> message. What does it mean?
>
> Ah, never mind. It's just a warning, that not all the sockets were
> collected and that
> dump _may_ fail if uncollected socket is in use by the task(s) you dump.
> BTW, there's
> BUG in this message, I'll fix one soon.
>
> > Thanks for your help!
>
> You're always welcome!
>
> -- Pavel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150604/6bc1bb51/attachment.html>