mysqld: errno: 24 - Too many open files

I think this should be a milestone for ubuntu 15.04

Hey postadelmaga: the file is in /lib/systemd/system/mysqld.service in debian and ubuntu. Those services are shipped in the mysql package, so closing the systemd tag (adding the tag though).

I looked at mysql upstream, and their service files doesn't let the limit of files to opened up. Do you have a particular use case with a very large database? I really vary on the idea we disable the limit checks on mysql.

Also, did you look at other distros, did they change the limit as well as distro-patch (it doesn't seem for me)? Maybe you can try opening an upstream bug to engage the discussion?

I'm a developer and I have 3/5 db on my machine, each one with many table ( 100+ ) however the main point is that using upstart I don't have issues, ideally the systemd behavior should be the same ...

On my machine, I'm on 15.04, /lib/systemd/system/mysqld.service is missing, which package provide it ?
- I have searched the file with apt-file and dpkg -l (mysql-server-5.6 and mysql-sever-core-5.6) but there is no track of it.

I have manually created that file with the following content, but I still have the issue:

[Service]
LimitNOFILE=infinity
LimitMEMLOCK=infinity

It will be great if you can share the content of your `mysqld.service` so I can add it manually.
Does I need to link this file some where ?

I re-added systemd because It affect the systemd boot option so I think it is good to have it listed with other problems with systemd and vivid. ( maybe it is bad idea in that case remove it )

It's already tagged systemd-boot, which is enough to make it appear on our radar (https://bugs.launchpad.net/ubuntu/+bugs?field.tag=systemd-boot)

the same problem, I can not change

in my.cnf
max_connections = 65535
open_files_limit = 65535

in /etc/sysctl.conf
fs.file-max = 2459688

in /etc/security/limits.conf

www-data soft nofile 65535
www-data hard nofile 65535
mysql soft nofile 65535
mysql hard nofile 65535
root soft nofile 65535
root hard nofile 65535

cat / proc / `pidof mysqld` / limits | egrep 'Limit | open files'
Limit Soft Limit Hard Limit Units
Max open files 1024 4096 files

max_connections 214

why so?

uname -a
Linux ubuntu 3.19.0-10-generic #10-Ubuntu SMP Mon Mar 23 16:16:45 UTC 2015 i686 i686 i686 GNU/Lin

 mysql -V
mysql Ver 14.14 Distrib 5.6.23, for debian-linux-gnu (i686) using EditLine wrapper

@cooolman

do you have this file on your system `/lib/systemd/system/mysqld.service` ?

I'm not sure why but if you boot with systemd you are supposed to set the limits in service file first:

LimitNOFILE=infinity
LimitMEMLOCK=infinity

After that mysqld service will be allowed to open more connection ( as per your setting in my.cnf )

On my system `/lib/systemd/system/mysqld.service` is missing.

@postadelmaga (postadelmaga)

file is not present, that this file should be?
these are:
LimitNOFILE = infinity
LimitMEMLOCK = infinity
what else?

/lib/systemd/system/mysql.service

[Unit]
Description=MySQL Community Server
After=network.target
After=syslog.target

[Install]
WantedBy=multi-user.target
Alias=mysql.service

[Service]
User=mysql
Group=mysql
PermissionsStartOnly=true
ExecStartPre=/usr/share/mysql/mysql-systemd-start pre
ExecStart=/usr/bin/mysqld_safe
ExecStartPost=/usr/share/mysql/mysql-systemd-start post
TimeoutSec=600
Restart=on-failure

added below
LimitNOFILE = infinity
LimitMEMLOCK = infinity

and made the team
systemctl daemon-reload
  helped, thanks for the tip

I'm reluctant to raise the default limit to infinity because this may introduce a security vulnerability due to select() macro overflow. See https://lists.ubuntu.com/archives/ubuntu-devel/2010-September/031446.html for details. If someone from upstream can confirm definitely that MySQL definitely does handle higher number file descriptors correctly though, then I have no objection.

I understand though that users do want to be able to tune the value. So, what else can we do? It seems to me that now that we're using systemd there are two different places where the setting can be made - from my.cnf, or from the systemd service definition - whereas previously users tended to do it in just my.cnf. Having it set in two places is confusing. my.cnf cannot raise beyond the systemd setting, but we cannot make the systemd setting "infinity" because of the security concern above.

So given that I don't want to change systemd's default to "infinity", I think it makes sense to expect users to change the systemd service definition (copy /lib/systemd/system/mysql.service to /etc/systemd/system/ and set LimitNOFILE etc there) if they want to change the default value, and to not set open_files_limit in my.cnf at all.

If this is reasonable, then this bug is Invalid. Is it reasonable? Comments appreciated.

Hi Robie,

The internal assessment here is that most appropriate solution would be
the one you have mentioned as the last option.

It would be easier if user owns the responsibility for creating and
managing the MySQL service file under /etc with following settings or
more as needed:
[Service]
LimitNOFILE=xxxxx
LimitMEMLOCK=xxxxx

This will help in avoiding any conflict between user settings and
package settings. We may add a comment to explain this to the users.

Please let me know if you need more information.

Regards,
Akhil

On Monday 30 March 2015 05:23 PM, Robie Basak wrote:
> I'm reluctant to raise the default limit to infinity because this may
> introduce a security vulnerability due to select() macro overflow. See
> https://lists.ubuntu.com/archives/ubuntu-
> devel/2010-September/031446.html for details. If someone from upstream
> can confirm definitely that MySQL definitely does handle higher number
> file descriptors correctly though, then I have no objection.
>
> I understand though that users do want to be able to tune the value. So,
> what else can we do? It seems to me that now that we're using systemd
> there are two different places where the setting can be made - from
> my.cnf, or from the systemd service definition - whereas previously
> users tended to do it in just my.cnf. Having it set in two places is
> confusing. my.cnf cannot raise beyond the systemd setting, but we cannot
> make the systemd setting "infinity" because of the security concern
> above.
>
> So given that I don't want to change systemd's default to "infinity", I
> think it makes sense to expect users to change the systemd service
> definition (copy /lib/systemd/system/mysql.service to
> /etc/systemd/system/ and set LimitNOFILE etc there) if they want to
> change the default value, and to not set open_files_limit in my.cnf at
> all.
>
> If this is reasonable, then this bug is Invalid. Is it reasonable?
> Comments appreciated.
>
> ** Changed in: mysql-5.6 (Ubuntu)
> Importance: Undecided => Medium
>
> ** Changed in: mysql-5.6 (Ubuntu)
> Status: New => Triaged
>

Thanks Akhil. I'll mark this bug as Invalid then, although we should mention this in our release notes.

This is broken again.

net4-dev# sysctl fs.file-max
fs.file-max = 3280263

Changing /lib/systemd/system/mysql.service has no effect on file limits.

Setting...

[Service]
... ... ...
LimitNOFILE=infinity
LimitMEMLOCK=infinity

Then...

systemctl daemon-reload
service mysql restart

net4-dev# cat /proc/$(cat /var/run/mysqld/mysqld.pid)/limits | grep files
Max open files 1024 4096 files