Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-30734

[ERROR] mariadbd: pam: cannot exec /usr/lib64/mysql/plugin/auth_pam_tool_dir/auth_pam_tool (errno: 12 "Cannot allocate memory")

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Won't Fix
    • 10.5.18
    • N/A
    • Plugin - pam
    • None
    • CentOS 7

    Description

      A customer reports the problem which is solved by decreasing the memory used by mariadb to less than half the ram.
      It is reproducible by having mariadb using 50%+1 of RAM.

      It seems similar to this:
      MDEV-26212
      MDEV-24535

      Which is fixed in 10.5.16 and the patch is also present in 10.5.18 enterprise.

      So apparently it didn't solve.

      Attachments

        Issue Links

          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-26212 PAM authentication fails with ENOMEM

          • Major - Major loss of function.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            serg Sergei Golubchik added a comment -

            It's not something we can fix. MDEV-26212 explains the problem:

            • before MDEV-26212 fix the server did
              • fork() — which reserved free memory in the same amount that the server was currently using
              • exec() — which threw all that memory away and replaced the process with a new one
            • the problem was that if the server already takes more than 50% of the RAM and Linux is not allowed to overcommit, fork() will fail.
            • MDEV-26212 replaced fork+exec with posix_spawn() that technically doesn't have to fork, because it knows he process will be replaced anyway.
            • but it depends on how posix_spawn() is implemented in glibc
              • CentOS 7 has glibc-2.17-196.el7.x86_64 where posix_spawn() calls fork() or vfork(). Which brings the problem back
              • On my laptop I see glibc-2.36 and there posix_spawn() does not seem to fork anymore.
            serg Sergei Golubchik added a comment - It's not something we can fix. MDEV-26212 explains the problem: before MDEV-26212 fix the server did fork() — which reserved free memory in the same amount that the server was currently using exec() — which threw all that memory away and replaced the process with a new one the problem was that if the server already takes more than 50% of the RAM and Linux is not allowed to overcommit, fork() will fail. MDEV-26212 replaced fork+exec with posix_spawn() that technically doesn't have to fork, because it knows he process will be replaced anyway. but it depends on how posix_spawn() is implemented in glibc CentOS 7 has glibc-2.17-196.el7.x86_64 where posix_spawn() calls fork() or vfork() . Which brings the problem back On my laptop I see glibc-2.36 and there posix_spawn() does not seem to fork anymore.
            serg Sergei Golubchik added a comment -

            2.17: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/spawni.c;h=2d3ae941dd19f0348ed95c0b957c68c3c0e9815d;hb=c758a6861537815c759cba2018a3b1abb1943842#l106

            2.36: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/spawni.c;h=ee843a2247bb577e9a8bcaca3a93af4831651be0;hb=c804cd1c00adde061ca51711f63068c103e94eef#l375

            serg Sergei Golubchik added a comment - 2.17: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/spawni.c;h=2d3ae941dd19f0348ed95c0b957c68c3c0e9815d;hb=c758a6861537815c759cba2018a3b1abb1943842#l106 2.36: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/spawni.c;h=ee843a2247bb577e9a8bcaca3a93af4831651be0;hb=c804cd1c00adde061ca51711f63068c103e94eef#l375
            claudio.nanni Claudio Nanni added a comment -

            Just checked: 2.26 introduced the change ( on 2.25 is still present the vfork()

            claudio.nanni Claudio Nanni added a comment - Just checked: 2.26 introduced the change ( on 2.25 is still present the vfork()

            People

              serg Sergei Golubchik
              claudio.nanni Claudio Nanni
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.