<div dir="ltr"><div>lookup_nsid_by_mnt_id() fails for fd = 0<br>(00.314250) Error (files-reg.c:817): Unable to look up the 10 mount<br><br>(00.311795) 1915 fdinfo 0: pos: 0x 0 flags: 400002/0<br><br>Output from lsof | grep 1915<br>1915 u0_a37 <b>0</b> ??? ??? ??? ???<b> /dev/null</b><br>1915 u0_a37 <b> 1</b> ??? ??? ??? ???<b> /dev/null</b><br>1915 u0_a37 <b>2</b> ??? ??? ??? ???<b> /dev/null</b><br><br># cat /proc/1915/fdinfo/0 <br>pos: 0<br>flags: 0400002<br>mnt_id: 10<br><br><br></div>However, I don't see mnt_id = 0xa (10) from mountinfo. Am I missing something? Any idea where to look for this?<br><br><br>(00.043094) type rootfs source rootfs mnt_id 0x19 s_dev 0x2 / @ ./ flags 0x1 options size=256340k,nr_inodes=64085<br>(00.043398) type tmpfs source tmpfs mnt_id 0x1a s_dev 0xb / @ ./dev flags 0x200002 options mode=755<br>(00.044501) type devpts source devpts mnt_id 0x1b s_dev 0xa / @ ./dev/pts flags 0x200000 options mode=600,ptmxmode=000<br>(00.045000) type cgroup source none mnt_id 0x1c s_dev 0xf / @ ./dev/memcg flags 0x200000 options memory<br>(00.045162) type cgroup source none mnt_id 0x1d s_dev 0x12 / @ ./dev/cpuctl flags 0x200000 options cpu<br>(00.045340) type proc source proc mnt_id 0x1e s_dev 0x4 / @ ./proc flags 0x200000 options<br>(00.045488) type sysfs source sysfs mnt_id 0x1f s_dev 0xc / @ ./sys flags 0x200000 options<br>(00.045699) type debugfs source debugfs mnt_id 0x20 s_dev 0x6 / @ ./sys/kernel/debug flags 0x200000 options<br>(00.045871) type tmpfs source none mnt_id 0x21 s_dev 0xe / @ ./sys/fs/cgroup flags 0x200000 options mode=750,gid=1000<br>(00.046066) type cgroup source none mnt_id 0x22 s_dev 0xf / @ ./sys/fs/cgroup/memory flags 0x200000 options memory<br>(00.046216) type cgroup source none mnt_id 0x23 s_dev 0xd / @ ./acct flags 0x200000 options cpuacct<br>(00.046418) type tmpfs source tmpfs mnt_id 0x24 s_dev 0x10 / @ ./mnt/asec flags 0x200000 options mode=755,gid=1000<br>(00.046616) type tmpfs source tmpfs mnt_id 0x25 s_dev 0x11 / @ ./mnt/obb flags 0x200000 options mode=755,gid=1000<br>(00.046794) type ext4 source /dev/block/mtdblock0 mnt_id 0x26 s_dev 0x1f00000 / @ ./system flags 0x200001 options data=ordered<br>(00.046980) type ext4 source /dev/block/mtdblock1 mnt_id 0x27 s_dev 0x1f00001 / @ ./data flags 0x406 options data=ordered<br>(00.047146) type ext4 source /dev/block/mtdblock2 mnt_id 0x28 s_dev 0x1f00002 / @ ./cache flags 0x406 options data=ordered<br><br><div><div class="gmail_extra"><div class="gmail_quote">On Thu, Jun 4, 2015 at 2:11 PM, Pavel Emelyanov <span dir="ltr"><<a href="mailto:xemul@parallels.com" target="_blank">xemul@parallels.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 06/04/2015 11:46 PM, CRIU criu wrote:<br>
<span class="">> On Thu, Jun 4, 2015 at 1:23 PM, Pavel Emelyanov <<a href="mailto:xemul@parallels.com">xemul@parallels.com</a> <mailto:<a href="mailto:xemul@parallels.com">xemul@parallels.com</a>>> wrote:<br>
><br>
> On 06/04/2015 05:35 PM, CRIU criu wrote:<br>
> > Can CRIU be used to checkpoint/restore a single process and not a process tree?<br>
><br>
> Without a patch -- no, it always scans for the process subtree starting from the<br>
> pid given.<br>
><br>
><br>
> Is there a patch already to do this?<br>
<br>
</span>Well, nope :) We used to have the ability to dump and restore a single process with<br>
CRIU, but removed one way before v1.0 was released.<br>
<span class=""><br>
> > I keep hitting this error message:<br>
> ><br>
> > if (item->sid == 0) {<br>
> ><br>
> > pr_err("A session leader of %d(%d) is outside of its pid namespace\n",<br>
> ><br>
> > item->pid.real, item->pid.virt);<br>
> ><br>
> > goto err_cure;<br>
> ><br>
> > }<br>
><br>
> But it's not about dumping a single task or a subtree, it's about the resources<br>
> leaking outside of what you dump :)<br>
><br>
><br>
> I agree. However, an Android process behaves very differently from a regular linux process<br>
> - some of the resources are released when a process goes in the background so we don't have<br>
> to dump everything because released resources will be reacquired upon resume (restore) when<br>
> brought into foreground again. That means the way we resume will change for Android. I will<br>
> fix this as I go along.<br>
<br>
</span>I see. Well, if there's a case to relax some restrictions CRIU impose on the linkage of<br>
resources tasks have, then the patch would be welcome :)<br>
<span class=""><br>
> I also see "Uncollected sockets! Will probably fail later." error message. What does it mean?<br>
<br>
</span>Ah, never mind. It's just a warning, that not all the sockets were collected and that<br>
dump _may_ fail if uncollected socket is in use by the task(s) you dump. BTW, there's<br>
BUG in this message, I'll fix one soon.<br>
<br>
> Thanks for your help!<br>
<br>
You're always welcome!<br>
<span class=""><font color="#888888"><br>
-- Pavel<br>
<br>
</font></span></blockquote></div><br></div></div></div>