[CRIU] dumping LXC 1.0 container failed - unable to open irmap-cache: No such file or directory

Wed Mar 5 11:29:23 PST 2014

On Wed, Mar 05, 2014 at 08:10:43PM +0400, Pavel Emelyanov wrote:
> On 03/05/2014 07:26 PM, Andrew Vagin wrote:
> > On Wed, Mar 05, 2014 at 05:10:44PM +0200, David Shwatrz wrote:
> >> Hi,
> >> Thanks, Andrew, for your quick response.
> >> The container is fedora 20 (as well as the host).
> > 
> > Sorry, but systemd inside CT is not supported yet for a few
> > reasons. We are going to support systemd in a near future.
> 
> Andrew, so what exact problem is David currently facing?
> The cgroupfs mounted inside CT?

/dev in CT is mounted as a slave of the external /dev

> 
> > Thanks.
> > 
> >>
> >> It is impossible to unmount systemd cgroups in this container:
> >>
> >> For example,
> >> umount /sys/fs/cgroup/systemd
> >> umount: /sys/fs/cgroup/systemd: target is busy
> >>         (In some cases useful info about processes that
> >>          use the device is found by lsof(8) or fuser(1).)
> >>
> >> I will test with an Ubuntu container.
> >>
> >> Following here is the requested output of cat /proc/4983/mountinfo
> >> gives:
> >> 255 195 8:5 /var/lib/lxc/fedora/rootfs / rw,relatime master:1 - ext4
> >> /dev/sda5 rw,data=ordered
> >> 256 255 0:5 /.lxc/fedora.ef29892550ef9cbf /dev rw,nosuid master:2 -
> >> devtmpfs devtmpfs rw,size=1514576k,nr_inodes=378644,mode=755

^^^^^^^^^^^^^^^^^^^^^^

Its master is the external /dev

> >> 196 256 0:39 / /dev/pts rw,relatime - devpts devpts
> >> rw,gid=5,mode=620,ptmxmode=666
> >> 193 255 0:37 / /proc rw,nosuid,nodev,noexec,relatime - proc proc rw
> >> 194 255 0:40 / /sys rw,nosuid,nodev,noexec,relatime - sysfs sysfs rw
> >> 197 256 0:41 / /dev/shm rw,nosuid,nodev - tmpfs tmpfs rw
> >> 198 255 0:42 / /run rw,nosuid,nodev - tmpfs tmpfs rw,mode=755
> >> 199 194 0:43 / /sys/fs/cgroup rw,nosuid,nodev,noexec - tmpfs tmpfs rw,mode=755
> >> 200 199 0:20 / /sys/fs/cgroup/systemd rw,nosuid,nodev,noexec,relatime
> >> - cgroup cgroup
> >> rw,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd
> >> 201 199 0:22 / /sys/fs/cgroup/cpuset rw,nosuid,nodev,noexec,relatime -
> >> cgroup cgroup rw,cpuset,clone_children
> >> 202 199 0:23 / /sys/fs/cgroup/cpu,cpuacct
> >> rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,cpuacct,cpu
> >> 203 199 0:24 / /sys/fs/cgroup/memory rw,nosuid,nodev,noexec,relatime -
> >> cgroup cgroup rw,memory
> >> 204 199 0:25 / /sys/fs/cgroup/devices rw,nosuid,nodev,noexec,relatime
> >> - cgroup cgroup rw,devices
> >> 205 199 0:26 / /sys/fs/cgroup/freezer rw,nosuid,nodev,noexec,relatime
> >> - cgroup cgroup rw,freezer
> >> 206 199 0:27 / /sys/fs/cgroup/net_cls rw,nosuid,nodev,noexec,relatime
> >> - cgroup cgroup rw,net_cls
> >> 207 199 0:28 / /sys/fs/cgroup/blkio rw,nosuid,nodev,noexec,relatime -
> >> cgroup cgroup rw,blkio
> >> 208 199 0:29 / /sys/fs/cgroup/perf_event
> >> rw,nosuid,nodev,noexec,relatime - cgroup cgroup rw,perf_event
> >> 209 199 0:30 / /sys/fs/cgroup/hugetlb rw,nosuid,nodev,noexec,relatime
> >> - cgroup cgroup rw,hugetlb
> >> 210 194 0:33 / /sys/kernel/config rw,relatime - configfs configfs rw
> >> 211 194 0:6 / /sys/kernel/debug rw,relatime - debugfs debugfs rw
> >> 212 255 0:44 / /tmp rw - tmpfs tmpfs rw
> >> 213 256 0:36 / /dev/mqueue rw,relatime - mqueue mqueue rw
> >> 214 256 0:45 / /dev/hugepages rw,relatime - hugetlbfs hugetlbfs rw
> >>
> >>
> >> DavidS
> >>
> >> On Wed, Mar 5, 2014 at 4:45 PM, Andrew Vagin <avagin at parallels.com> wrote:
> >>> On Wed, Mar 05, 2014 at 03:54:33PM +0200, David Shwatrz wrote:
> >>>> Christopher,
> >>>> Yes, you are absolutely right. In tests which I had done with a simple
> >>>> process (not  in a containers environment), everything with c/r worked
> >>>> fine, but this same message still appeared.
> >>>>
> >>>>> Error (mount.c:430): Mount 327 (master_id: 2 shared_id: 0) has >unreachable sharing
> >>>>
> >>>> Any ideas how can we tell to which mount/mount point is this message related ?
> >>>
> >>> Could you show content of /proc/4983/mountinfo?
> >>>
> >>> What distribution do you use in CT?
> >>>
> >>> criu doesn't support cgroup, hugetlbfs, fusectl, configfs, mqueue,
> >>> debugfs file systems in containers, so you should umount them from CT.
> >>>
> >>> http://criu.org/LXC
> >>>
> >>>>
> >>>> Regards.
> >>>> DavidS
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Mar 5, 2014 at 2:55 PM, Christopher Covington
> >>>> <cov at codeaurora.org> wrote:
> >>>>> On 03/05/2014 05:32 AM, David Shwatrz wrote:
> >>>>>> Hello,
> >>>>>> I am trying to checkpoint an LXC 1.0 container and it fails.
> >>>>>> I am trying it with crtools 1.2.
> >>>>>>
> >>>>>> The command I use is:
> >>>>>> criu dump -t 4983 -v4 -D images --shell-job --ext-unix-sk -o dump.log
> >>>>>> --tcp-established --file-locks
> >>>>>> and the log file shows this as a first error:
> >>>>>> unable to open irmap-cache: No such file or directory
> >>>>>> the full log fine is in:
> >>>>>> http://pastebin.com/e3MKxmBg
> >>>>>
> >>>>> The irmap stuff is spurious. This looks like your real error:
> >>>>>
> >>>>> Error (mount.c:430): Mount 327 (master_id: 2 shared_id: 0) has unreachable sharing
> >>>>>
> >>>>> Regards,
> >>>>> Christopher
> >>>>>
> >>>>> --
> >>>>> Employee of Qualcomm Innovation Center, Inc.
> >>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
> >>>>> hosted by the Linux Foundation.
> >>>> _______________________________________________
> >>>> CRIU mailing list
> >>>> CRIU at openvz.org
> >>>> https://lists.openvz.org/mailman/listinfo/criu
> > _______________________________________________
> > CRIU mailing list
> > CRIU at openvz.org
> > https://lists.openvz.org/mailman/listinfo/criu
> > .
> > 
> 
>