ITPub博客

首页 > 数据库 > Oracle > docker中使用systemctl命令时报Too many open files错误

docker中使用systemctl命令时报Too many open files错误

原创 Oracle 作者:lhrbest 时间:2021-03-03 12:31:46 0 删除 编辑


在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"生效即可。


Too many open files的四种解决办法

一  单个进程打开文件句柄数过多

ulimit中的nofile表示单进程可以打开的最大文件句柄数,可以通过ulimit -a查看,子进程默认继承父进程的限制(注意,是继承,不是共享,子进程和父进程打开的文件句柄数是单独算的)。

网上还有一种解读是nofile表示单用户可以打开的文件句柄数,因为他们在limit.conf中看到类似于“openstack soft nofile 65536”,便认为是openstack用户最多可以打开的文件句柄数。该解读是错误的,“openstack soft nofile 65536”表示的含义是当你执行"su - openstack"切换到openstack用户后,你创建的所有进程最大可以打开的文件句柄数是65536。

要查看一个进程可以打开的文件句柄数,可以通过“cat /proc/<pid>/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

........................................................................................................................

● 本文作者:小麦苗,部分内容整理自网络,若有侵权请联系小麦苗删除

● 本文在个人微 信公众号( )上有同步更新

● QQ群号: 230161599 、618766405,微信群私聊

● 个人QQ号(646634621),微 信号(db_bao),注明添加缘由

● 于 2021年3月完成

● 最新修改时间:2021年3月

● 版权所有,欢迎分享本文,转载请保留出处

........................................................................................................................

小麦苗的微店

● 小麦苗出版的数据库类丛书: 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/

........................................................................................................................

请扫描下面的二维码来关注小麦苗的微 信公众号( )及QQ群(230161599、618766405)、添加小麦苗微 信(db_bao), 学习最实用的数据库技术。

........................................................................................................................

 

 



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26736162/viewspace-2760823/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
【QQ:646634621】【微信:db_bao】【微信公众号:DB宝】【11g、12c OCM】【QQ群:230161599、618766405】【《数据库笔试面试宝典》作者】【OCP、OCM、高可用(RAC+DG+OGG)、MySQL培训班已开讲,只讲实用内容】

注册时间:2012-09-23

  • 博文量
    1611
  • 访问量
    9379699