[CRIU] failure dumping nginx in docker container

[Saied Kazemi]

Thanks for the explanation.  From your explanation, I assume that back
porting Al Viro's patch to 3.18 is not an option.  Correct?

--Saied


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

> On 06/04/2015 11:22 PM, Saied Kazemi wrote:
> > I am running into the exact same CRIU failure with a mysqld server
> running in a container:
> >
> > (00.007793) Error (proc_parse.c:404): Can't handle non-regular mapping
> on 26317's map 7ff7022cc000
> >
> > for the following segment:
> >
> > 7ff7022cc000-7ff7022ce000 rw-s 00000000 00:0a 72033
> /[aio] (deleted)
> >
> > I am using CRIU 1.6 on a 3.18.0 kernel.  Below is the output of strace.
> Kernel successfully opens the file:
>
> Ah! This explains everything, please, see more details below :)
>
> > # criu --version
> > Version: 1.6
> > GitID: v1.6-5-g5e1a8a2
> > # criu check
> > Error (cr-check.c:665): AIO remap doesn't work properly
>
> Yup :)
>
> > Error (cr-check.c:681): fdinfo doesn't contain the lock field
> > # zcat /proc/config.gz | grep AIO
> > CONFIG_AIO=y
> > # CONFIG_DELL_WMI_AIO is not set
> > # strace ./aio_test /proc/26317/map_files/7ff7022cc000-7ff7022ce000
> > execve("./aio_test", ["./aio_test",
> "/proc/26317/map_files/7ff7022cc0"...], [/* 17 vars */]) = 0
> > uname({sys="Linux", node="saied-cr-vm", ...}) = 0
> > brk(0)                                  = 0x203d000
> > brk(0x203e1c0)                          = 0x203e1c0
> > arch_prctl(ARCH_SET_FS, 0x203d880)      = 0
> > readlink("/proc/self/exe", "/home/saied/aio_test", 4096) = 20
> > brk(0x205f1c0)                          = 0x205f1c0
> > brk(0x2060000)                          = 0x2060000
> > access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or
> directory)
> > open("/proc/26317/map_files/7ff7022cc000-7ff7022ce000", O_RDONLY) = 3
> > exit_group(3)                           = ?
> > +++ exited with 3 +++
> >
> > Any ideas?
>
> So, there's a commit in the kernel bd9b51e7 from Al Viro which actually
> made files
> like AIO and some more report ENXIO when trying to open() those via
> /proc/pid/blah
> links. And this patch appeared in 3.19. Other than this, ability to remap
> the AIO
> ring -- the crucial thing to restore AIO -- appeared with the e4a0d3e72
> commit from
> me also in 3.19.
>
> When doing the AIO support I took the 3.19 kernel and implemented dump and
> restore
> according to how the kernel worked with AIO-s that time -- reporting ENXIO
> on
> open and letting to remap it. On 3.18 AIO C/R wouldn't work, even if we
> teach CRIU
> to detect the ring, on restore we'll hit the problem with inability to put
> the
> ring into proper place.
>
> -- Pavel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150604/5a337173/attachment.html>