We've been having some trouble with a server that's had automatic updates enabled on it. This past Monday, it seems that a new kernel was installed, and after rebooting our MySQL server started behaving like its file limit had been exceeded. I check the mysql user's ulimit -n output, and sure enough it's set to 1024.

I try to change this in /etc/security/limits.conf like so:

mysql           soft    nofile  20000
mysql           hard    nofile  25000

then when I try to check the user's ulimit again, it's still set to 1024. Rebooting hasn't had any effect either. It's like this file isn't being read at all.

Also, setting the ulimit manually does work.

Kernel version is 3.13.0-37-generic

  • By using the same procedure as I used to test it in the first place. Su to the user, enter ulimit -n on the command line.
    – Ernie
    Oct 21 '14 at 16:21
  • Are you kidding me? su mysql -s /bin/bash
    – Ernie
    Oct 21 '14 at 16:45
  • Not kidding, just someone who uses sudo more than su. That said, that particular test is unreliable. On a Debian squeeze machine, www-data with limit set to 16384 still shows 1024 for the limit when checked using su www-data -s /bin/bash.
    – muru
    Oct 21 '14 at 16:50
  • well that explains why the test has been failing, now all I need to do is discover why MySQL is getting Error 24's for having too many files open, when the limit is set to 25000 files.
    – Ernie
    Oct 21 '14 at 17:00
  • Could you try testing ulimit -n after starting a shell via sudo -u www-data /bin/bash -l?
    – muru
    Oct 21 '14 at 17:24

It turned out this was an error in the MySQL configuration. The variable open_files_limit was in the wrong section of /etc/mysql/my.cnf, and wouldn't load.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.