<div dir="ltr">Just wanted to confirm that I was able to get everything running directly on the host and able to run the same test you posted. So the issue is running inside of a docker container.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 3, 2015 at 8:57 AM, Ross Boucher <span dir="ltr"><<a href="mailto:rboucher@gmail.com" target="_blank">rboucher@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm running criu through the nsinit checkpoint command, but I'm running both inside of a Docker container -- that is, I've used the Dockerfile in libcontainer to build an image that has criu and nsinit installed, and then I launch a container with that image, and inside of that container I then ran the nsinit commands to create another container and try to checkpoint it. <div><br></div><div>The problem, I think, is at the Docker layer, based on the aufs items in the dump.log?</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 2, 2015 at 8:45 PM, Saied Kazemi <span dir="ltr"><<a href="mailto:saied@google.com" target="_blank">saied@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Ross,<div><br></div><div>I just tried to re-produce the problem that you see by creating my container's root filesystem at / but both checkpoint and restore succeeded for me (see below). How exactly are you setting up your container? Are you running CRIU directly or are you using nsinit to checkpoint your container?</div><div><br></div><div>Please note that due to a host of other activities, unfortunately I won't be able to respond quickly.</div><div><br></div><div>--Saied</div><div><br></div><div>[Terminal A]</div><div># cd /</div><div># <span>curl </span><span>-sSL</span><span> </span><span>'</span><a href="https://github.com/jpetazzo/docker-" target="_blank">https://github.com/jpetazzo/docker-</a><span>busybox</span>/raw/buildroot-2014.02/rootfs.tar<span>'</span><span> </span><span>></span><span> /tmp/rootfs.tar</span></div><div><span># </span>cat /tmp/rootfs.tar <span>|</span> tar <span>-xC</span> <span>"</span><span>$container_dir</span><span>"</span> <span>2</span><span>></span> /dev/null</div><div># cd /busybox</div><div># nsinit exec -- sh -i</div><div>sh: can't access tty; job control turned off</div><div>/ #</div><div><br></div><div>[Terminal B]</div><div># cd /busybox</div><div># nsinit -criu /usr/local/bin/criu checkpoint</div><div>#</div><div><br></div><div>[Terminal A]</div><div># mount --rbind /busybox /busybox</div><div># cd /busybox<br></div><div># nsinit -criu /usr/local/bin/criu restore</div><div>/ #</div><div><br></div>
<div><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Thu, Apr 2, 2015 at 4:51 PM, Ross Boucher <span dir="ltr"><<a href="mailto:rboucher@gmail.com" target="_blank">rboucher@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">I'm running into a failure when trying to checkpoint (with the as of yet unmerged support being worked on libcontainer). The command I'm running is:<div><br></div><div>>>> criu dump -v4 -D /busybox/nsinit/checkpoint -o dump.log --root /busybox --manage-cgroups --evasive-devices -t 51<br></div><div><br></div><div>Which eventually ends up with this error:</div><div><br></div><div>(00.017527) Replacing /var/lib/docker/aufs/diff/df29663e06373227d372bdd13867dbdce00bf02dac9627679ee3d4985021beb0/busybox/bin/busybox with /busybox/bin/busybox<br></div><div>(00.017537) Saved AUFS paths ./busybox/bin/busybox and /busybox/busybox/bin/busybox</div><div>(00.017575) Error (sysfs_parse.c:304): Failed stat on map 400000 (/busybox/busybox/bin/busybox): No such file or directory</div><div>(00.017583) Error (proc_parse.c:589): Can't open 51's mapfile link 400000: No such file or directory</div><div><br></div><div>(full dump: <a href="https://gist.github.com/boucher/d2539bcaa1311c5d5f5c" target="_blank">https://gist.github.com/boucher/d2539bcaa1311c5d5f5c</a>)<br></div><div><br></div><div>I can see in the criu source that this is part of potentially trying to workaround a kernel bug (according to the comments around fixup_aufs_vma_fd). I'm not entirely sure what the expected behavior is, or why /busybox/bin/busybox seems to get turned into the relative version ./busybox/bin/busybox. </div><div><br></div><div>Any ideas?</div><div><br></div></div>
<br></div></div>_______________________________________________<br>
CRIU mailing list<br>
<a href="mailto:CRIU@openvz.org" target="_blank">CRIU@openvz.org</a><br>
<a href="https://lists.openvz.org/mailman/listinfo/criu" target="_blank">https://lists.openvz.org/mailman/listinfo/criu</a><br>
<br></blockquote></div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>