在docker的容器内使用systemctl启动服务时，报错：
[root@lhrorchestrator /]# systemctl start mysql
Error: Too many open files
Authorization not available. Check if polkit service is running or see debug message for more information.
这里不仅仅是mysql服务，任何服务使用systemctl启动都会报错，另外，这里绝对不是由于系统文件open-files达到最大数引起的。
查了好几天的原因，最后使用journalctl -xe命令查看日志，突然发现了一个不一样的错误：“inotify_init1() failed: Too many open files”
[root@lhrorchestrator /]# journalctl -xe
Mar 03 12:15:53 lhrorchestrator systemd[1]: inotify_init1() failed: Too many open files
Mar 03 12:15:53 lhrorchestrator systemd[1]: Unit systemd-udevd.service entered failed state.
Mar 03 12:15:53 lhrorchestrator systemd[1]: systemd-udevd.service failed.
Mar 03 12:15:53 lhrorchestrator systemd[1]: systemd-udevd.service has no holdoff time, scheduling restart.
Mar 03 12:15:53 lhrorchestrator systemd[1]: Stopped udev Kernel Device Manager.
-- Subject: Unit systemd-udevd.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit systemd-udevd.service has finished shutting down.
Mar 03 12:15:53 lhrorchestrator systemd[1]: inotify_init1() failed: Too many open files
Mar 03 12:15:53 lhrorchestrator systemd[1]: start request repeated too quickly for systemd-udevd.service
Mar 03 12:15:53 lhrorchestrator systemd[1]: Failed to start udev Kernel Device Manager.
-- Subject: Unit systemd-udevd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit systemd-udevd.service has failed.
--
-- The result is failed.
Mar 03 12:15:53 lhrorchestrator systemd[1]: inotify_init1() failed: Too many open files
Mar 03 12:15:53 lhrorchestrator systemd[1]: inotify_init1() failed: Too many open files
Mar 03 12:15:53 lhrorchestrator systemd[1]: Unit systemd-udevd.service entered failed state.
Mar 03 12:15:53 lhrorchestrator systemd[1]: systemd-udevd.service failed.
百度搜索“inotify_init1() failed: Too many open files”：
notify是linux提供的一种监控机制，可以监控文件系统的变化。该机制受到2个内核参数的影响：“fs.inotify.max_user_instances”和“fs.inotify.max_user_watches”，其中“fs.inotify.max_user_instances”表示每个用户最多可以创建的inotify instances数量上限，“fs.inotify.max_user_watches”表示每个用户同时可以添加的watch数目，当出现too many open files问题而上面三种方法都无法解决时，可以尝试通过修改这2个内核参数来生效。修改方法是修改"/etc/sysctl.conf"文件，并执行"sysctl -p"。
所以，解决很简单：
[root@docker35 ~]# more /etc/sysctl.conf | grep fs
fs.file-max=9000000
fs.inotify.max_user_instances = 1000000
fs.inotify.max_user_watches = 1000000
再
执行"sysctl -p"生效即可。
一 单个进程打开文件句柄数过多
ulimit中的nofile表示单进程可以打开的最大文件句柄数，可以通过ulimit -a查看，子进程默认继承父进程的限制（注意，是继承，不是共享，子进程和父进程打开的文件句柄数是单独算的）。
网上还有一种解读是nofile表示单用户可以打开的文件句柄数，因为他们在limit.conf中看到类似于“openstack soft nofile 65536”，便认为是openstack用户最多可以打开的文件句柄数。该解读是错误的，“openstack soft nofile 65536”表示的含义是当你执行"su - openstack"切换到openstack用户后，你创建的所有进程最大可以打开的文件句柄数是65536。
要查看一个进程可以打开的文件句柄数，可以通过“cat /proc//limits”查看。
要修改ulimit中的nofile，可以通过修改/etc/security/limits.conf文件，在其中加入类似“openstack soft nofile 65536”的语句来进行修改。修改完成后，可以通过“su - openstack”切换用户，或者重新登录，来使该配置生效。
要动态修改一个进程的限制，可以使用prlimit命令，具体用法为：“prlimit --pid ${pid} --nofile=102400:102400”。
二 操作系统打开的文件句柄数过多
整个操作系统可以打开的文件句柄数是有限的，受内核参数“fs.file-max”影响。
可以通过执行“echo 100000000 > /proc/sys/fs/file-max”命令来动态修改该值，也可以通过修改"/etc/sysctl.conf"文件来永久修改该值。
三 systemd对该进程进行了限制
该场景仅针对被systemd管理的进程（也就是可以通过systemctl来控制的进程）生效，可以通过修改该进程的service文件（通常在/etc/systemd/system/目录下），在“[Service]”下面添加“LimitNOFILE=20480000”来实现，修改完成之后需要执行"systemctl daemon-reload"来使该配置生效。
四 inotify达到上限
inotify是linux提供的一种监控机制，可以监控文件系统的变化。该机制受到2个内核参数的影响：“fs.inotify.max_user_instances”和“fs.inotify.max_user_watches”，其中“fs.inotify.max_user_instances”表示每个用户最多可以创建的inotify instances数量上限，“fs.inotify.max_user_watches”表示么个用户同时可以添加的watch数目，当出现too many open files问题而上面三种方法都无法解决时，可以尝试通过修改这2个内核参数来生效。修改方法是修改"/etc/sysctl.conf"文件，并执行"sysctl -p"。
用到的命令：
-- 修改文件数
ulimit -a
ulimit -u unlimited
ulimit -HSn 1048576
/etc/security/limits.conf
* soft nofile 1048576
* hard nofile 1048576
/etc/pam.d/login
session required /lib64/security/pam_limits.so
/etc/sysctl.conf
fs.file-max=9000000
fs.inotify.max_user_instances = 1000000
fs.inotify.max_user_watches = 1000000
sysctl -p
/etc/security/limits.d/20-nproc.conf
* soft nproc unlimited
/usr/lib/systemd/system/polkit.service
LimitNOFILE=1048576
LimitNPROC=1048576
systemctl daemon-reload
--查看限制
cat /proc/944/limits
ls /proc/944/fd/ | wc -l
lsof | wc -l
About Me
|
........................................................................................................................
● 本文作者：小麦苗，部分内容整理自网络，若有侵权请联系小麦苗删除
● 本文在个人微 信公众号（
DB宝）上有同步更新
● QQ群号：
230161599
、618766405，微信群私聊
● 个人QQ号（646634621），微 信号（db_bao），注明添加缘由
● 于 2021年3月完成
● 最新修改时间：2021年3月
● 版权所有，欢迎分享本文，转载请保留出处
........................................................................................................................
●
小麦苗的微店：
https://weidian.com/s/793741433?wfr=c&ifr=shopdetail
● 小麦苗出版的数据库类丛书：
http://blog.itpub.net/26736162/viewspace-2142121/
●
小麦苗OCP、OCM、高可用、MySQL、DBA学习班：
http://blog.itpub.net/26736162/viewspace-2148098/
● 数据库笔试面试题库及解答：
http://blog.itpub.net/26736162/viewspace-2134706/
........................................................................................................................
请扫描下面的二维码来关注小麦苗的微 信公众号（
DB宝）及QQ群（230161599、618766405）、添加小麦苗微 信（db_bao），
学习最实用的数据库技术。
........................................................................................................................ |