100

I have a problem with my MySQL error log which currently mostly consists of "mbind: Operation not permitted" lines (see below). Why does it happen and how do I fix it?

It's the "mostly" part that bothers me. As you can see below, not all lines are "mbind: Operation not permitted". I suspect that MySQL query errors should be instead of that line, but for some reason they can't be written into the file.

MySQL itself is a Docker container where log files are volumed via:

volumes:
- ./mysql/log:/var/log/mysql

What's interesting is that:

  • "docker logs mysql_container" shows nothing...
  • slow.log, which resides in the same volume folder, is completely OK and has real slow log lines in it, no "mbind: Operation not permitted" whatsoever!
  • same as slow.log goes to general.log — no problem here, either

Any ideas? Thank you in advance.

2019-04-07T12:56:22.478504Z 0 [Warning] [MY-011070] [Server] 'Disabling symbolic links using --skip-symbolic-links (or equivalent) is the default. Consider not using this option as it' is deprecated and will be removed in a future release.
2019-04-07T12:56:22.478533Z 0 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2019-04-07T12:56:22.478605Z 0 [System] [MY-010116] [Server] /usr/sbin/mysqld (mysqld 8.0.15) starting as process 1
2019-04-07T12:56:22.480115Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
2019-04-07T12:56:22.480122Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead.
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
mbind: Operation not permitted
[same line goes forever]

P.S. MySQL starts and runs well, no problem with that. It's just this error.log that keeps bothering me and prevents me from seeing actual errors.

gamasexual
  • 1,267
  • 2
  • 8
  • 9

2 Answers2

175

Add the capability CAP_SYS_NICE to your container until MySQL server can handle the error itself "silently".

service:
  mysql:
    image: mysql:8.0.15
    # ...
    cap_add:
      - SYS_NICE  # CAP_SYS_NICE

If you don't have docker-compose, then you can define CAP_SYS_NICE via

docker run --cap-add=sys_nice -d mysql

References:

Dale K
  • 25,246
  • 15
  • 42
  • 71
Laurent Gosselin
  • 2,051
  • 1
  • 11
  • 10
  • 2
    Is anyone aware of any issues with this solution? Can this cause the hardware device (not the container) to hang completely/crash? I can see that this allows MySQL to hang the system from https://unix.stackexchange.com/questions/455084/giving-users-scheduling-privileges – Hugo Pakula Dec 05 '19 at 23:13
  • 4
    Generally speaking, when a process is allowed to change its priority or niceness, it can set itself in an ultra high priority and be scheduled on the CPU more often than all other processes. So yes there is a risk that the process could starve other processes on the host when priority/niceness is chosen poorly. But so far I have never experienced such a problem with MySQL. Maybe am I not using the feature that needs this? – Laurent Gosselin Dec 11 '19 at 13:12
  • 5
    In case you are using Docker Stack/Swarm, `cap_add`/`security_opt` is not supported (https://github.com/moby/moby/issues/25885). – tsauerwein Mar 02 '20 at 09:07
  • 4
    why is this happening? I hadn't problems in the past with mysql, and the solution doesn't seem safe, is docker mysql image v8 specific problem? is there going to be a better solution later and this is a quick fix? – Rodrigo Sep 04 '20 at 22:53
  • it didn't work, i'd change to v5.7 because it's for test anyway, i hope this isn't going happen on production... :) – Rodrigo Sep 04 '20 at 23:21
  • So what exactly is behind this problem? – Fauzan Edris May 12 '21 at 07:39
  • 5
    Without CAP_SYS_NICE enabled, MySQL won't be able to handle thread priorities, and I guess you will then loose a new feature introduced with MySQL 8 (I believe Resource Groups https://dev.mysql.com/doc/refman/8.0/en/resource-groups.html). MySQL should warn us *once* during startup. Instead (not sure whether it is still the case nowadays), it fills the disk with this message. – Laurent Gosselin May 12 '21 at 15:38
  • 2
    So I'm using MySQL 8.0 and the error message persists... Is this solution only applicable for 5.7? Anyone knows if another CAP solves this issue? – Davi S Evangelista Jun 15 '21 at 21:07
  • `- SYS_NICE **# CAP_SYS_NICE**` Documentation of the year award has been granted – Eugene Apr 29 '22 at 09:40
  • @LaurentGosselin Explaining the error would be useful in the answer itself. – gre_gor Dec 13 '22 at 11:19
14

Adding the security_opt option in docker-compose.yml helped to solve this problem:

database:
  image: mysql:latest
  container_name: mysql_0
  ports:
    - "3306:3306"
  security_opt:
    - seccomp:unconfined
gamasexual
  • 1,267
  • 2
  • 8
  • 9