Re: PANIC: could not flush dirty data: Operation not permitted power8, Redhat Centos

On Mon, Aug 19, 2019 at 7:32 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Wed, Apr 17, 2019 at 1:04 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > On Mon, Apr 15, 2019 at 7:57 PM <zedaardv(at)gmail(dot)com> wrote:
> > > I forgot to mention that this is happening in a docker container.
> >
> > Huh, so there may be some configuration of Linux container that can
> > fail here with EPERM, even though that error that does not appear in
> > the man page, and doesn't make much intuitive sense. Would be good to
> > figure out how that happens.
>
> Steve Dodd ran into the same problem in Borg[1]. It looks like what's
> happening here is that on PowerPC and ARM systems, there is a second
> system call sync_file_range2 that has the arguments arranged in a
> better order for their calling conventions (see Notes section of man
> sync_file_range), and glibc helpfully translates for you, but some
> container technologies forgot to include sync_file_range2 in their
> syscall forwarding table. Perhaps we should just handle this with the
> not_implemented_by_kernel mechanism I added for WSL.

I've just heard that it was fixed overnight in seccomp, which is
probably what Docker is using to give you EPERM for syscalls it
doesn't like the look of:

https://github.com/systemd/systemd/pull/13352/commits/90ddac6087b5f8f3736364cfdf698e713f7e8869

Not being a Docker user, I'm sure if/when that will flow into the
right places in a timely fashion but if not it looks like you can
always configure your own profile or take one from somewhere else,
probably something like this:

https://github.com/moby/moby/commit/52d8f582c331e35f7b841171a1c22e2d9bbfd0b8

So it looks like we don't need to do anything at all on our side,
unless someone knows better.

--
Thomas Munro
https://enterprisedb.com