[CRIU] Debugging checkpoint failure
Saied Kazemi
saied at google.com
Thu Apr 2 20:45:43 PDT 2015
Hi Ross,
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?
Please note that due to a host of other activities, unfortunately I won't
be able to respond quickly.
--Saied
[Terminal A]
# cd /
# curl -sSL 'https://github.com/jpetazzo/docker-busybox
/raw/buildroot-2014.02/rootfs.tar' > /tmp/rootfs.tar
# cat /tmp/rootfs.tar | tar -xC "$container_dir" 2> /dev/null
# cd /busybox
# nsinit exec -- sh -i
sh: can't access tty; job control turned off
/ #
[Terminal B]
# cd /busybox
# nsinit -criu /usr/local/bin/criu checkpoint
#
[Terminal A]
# mount --rbind /busybox /busybox
# cd /busybox
# nsinit -criu /usr/local/bin/criu restore
/ #
On Thu, Apr 2, 2015 at 4:51 PM, Ross Boucher <rboucher at gmail.com> wrote:
> 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:
>
> >>> criu dump -v4 -D /busybox/nsinit/checkpoint -o dump.log --root
> /busybox --manage-cgroups --evasive-devices -t 51
>
> Which eventually ends up with this error:
>
> (00.017527) Replacing
> /var/lib/docker/aufs/diff/df29663e06373227d372bdd13867dbdce00bf02dac9627679ee3d4985021beb0/busybox/bin/busybox
> with /busybox/bin/busybox
> (00.017537) Saved AUFS paths ./busybox/bin/busybox and
> /busybox/busybox/bin/busybox
> (00.017575) Error (sysfs_parse.c:304): Failed stat on map 400000
> (/busybox/busybox/bin/busybox): No such file or directory
> (00.017583) Error (proc_parse.c:589): Can't open 51's mapfile link 400000:
> No such file or directory
>
> (full dump: https://gist.github.com/boucher/d2539bcaa1311c5d5f5c)
>
> 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.
>
> Any ideas?
>
>
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150402/6d76a0e8/attachment.html>
More information about the CRIU
mailing list