更新服务器后，MySQL无法打开文件：errno：24
Ubuntu： 12.04 LTS（Linux mysql02 3.2.0-40-generic＃64-Ubuntu SMP Mon Mar 25 21:22:10 UTC 2013 x86_64 x86_64 x86_64 GNU / Linux）
MySQL： Ubuntu发行版5.5.31
Apparmor：删除了！
服务器已运行坚实一年多了。 然后本周一MySQL开始失败。 更新导致了问题，我们无法弄清楚它是什么。 我们甚至试图回滚到MySQL 5.5.30，但没有运气。 我们返回5.5.31。
MySQL错误日志条目：
130430 7:55:46 [ERROR] Error in accept: Too many open files 130430 7:55:46 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/fclvod.frm' (errno: 24) 130430 7:55:46 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/fcnote.frm' (errno: 24) 130430 7:55:47 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/ffcont.frm' (errno: 24) 130430 7:55:47 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/ffcontv.frm' (errno: 24) 130430 7:55:47 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/ffnote.frm' (errno: 24) 130430 7:55:47 [ERROR] /usr/sbin/mysqld: Can't open file: './eci_elite_test/frcfcl.frm' (errno: 24) 看来我们遇到了ulimit问题。 我们完全删除了APPARMOR。 我们增加了/etc/security/limits.conf但仍然没有运气：
# Out of desperation.... * soft nofile 49152 * hard nofile 65536 # No effect!?!!? #mysql soft nofile 49152 #mysql hard nofile 65536
并显示limits.conf正在工作：
root@mysql02:/etc/security# ulimit -Sa | grep "open files" open files (-n) 49152 root@mysql02:/etc/security# ulimit -Ha | grep "open files" open files (-n) 65536
以下是my.cnf中的重要条目
[mysqld_safe] open_files_limit = 16384 [mysqld] open_files_limit = 16384
然而：
root@mysql02:/etc/mysql# mysqladmin -u root -pThePassword variables| grep open_files_limit open_files_limit | 1024
我们完全被困住了。 任何帮助将不胜感激。
操作系统： Ubuntu（Debian）部署
MySQL服务器选项： open-files-limit
似乎Debian upstart不使用/etc/security/limits.conf中定义的参数，所以当你通过service命令启动mysql时（在upstart下），它会覆盖那些定义的限制并使用默认值1024 。
解决方案是修改定义upstart服务的mysql.conf文件，它位于/etc/init/mysql.conf中，并在预启动块之前添加以下行：
# NB: Upstart scripts do not respect # /etc/security/limits.conf, so the open-file limits # settings need to be applied here. limit nofile 32000 32000 limit nproc 32000 32000
参考文献：
在Ubuntu 15.10上遇到同样的问题。
https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1434758 – 带来了解决方案：
- 检查/lib/systemd/system/mysql.service或/lib/systemd/system/mysqld.service是否存在
-
（在我的情况下）如果没有，创建/lib/systemd/system/mysql.service并将内容复制到此文件https://bugs.launchpad.net/ubuntu/+source/mysql-5.6/+bug/1434758/ comments / 11并在文件中的某处添加两行
LimitNOFILE=infinity LimitMEMLOCK=infinity -
如果存在一个或两个文件，请检查是否包含这两行：
LimitNOFILE=infinity LimitMEMLOCK=infinity - 执行
systemctl daemon-reload
……一切都应该没问题。
由于以上都没有解决我的问题（只导致系统内存不足），这是我找到的解决方案：
在/etc/mysql/my.conf您需要增加MySQL内部的open_files_limit。 所以暂时将其添加到配置并重启MySQL。
[mysqld] open_files_limit = 100000
sudo /etc/init.d/mysql restart
运行导致过多打开文件错误的操作后，您可以将配置更改回其默认值并再次重新启动MySQL。
谢谢你的解决方法。 但对我来说，这个问题已被另外两个事实所掩盖。
- 我的数据目录与默认安装不同。 出于多种原因，无论是历史还是技术。
- 我正在从一个非常旧的安装升级，通过一些后端和前端端口。 在新安装的MySQL 5.5的第一次启动时，InnoDB引擎未激活（配置文件中禁用了内部实现，但5.5中没有以前版本中提供的插件），并且创建了升级标记而未实际升级任何表格。
在修复InnoDB问题之后，它仍然随地吐痰
mysql> SHOW DATABASES; ERROR 1018 (HY000): Can't read dir of '.' (errno: 24)
我必须在根控制台启动mysqld并手动重启
/usr/bin/mysql_upgrade --defaults-extra-file=/etc/mysql/debian.cnf --force
然后服务器开始显示数据库，但无法访问某些表。 增加限制的解决方法修复了其余问题，谢谢！