背景：公司有个项目服务器为CentOS Linux release 7.6.1810 (Core) 通过supervisor 控制程序启动，最近频繁出现程序假死的情况，经过追加程序日志看到 ：

accept() failed. Error: Too many open files[24]

统计当前进程打开文件数，发现只有1000个左右

lsof -p PID |  wc -l 

查看当前系统级最大文件数参数：

ulimit -a
open files                      (-n) 1000000

查看/etc/security/limits.conf

# End of file
* soft nproc 1000000
* hard nproc 1000000
* soft nofile 1000000
* hard nofile 1000000

查看/etc/security/limits.d/20-nproc.conf

*          soft    nproc     4096
root       soft    nproc     unlimited

　　根据以上信息，暂时看不出问题，毕竟系统级打开文件数1000000 而进程设置至少也是4096，按理说不可能出现文件数不够的情况，继续排查当前进程的 limits文件

cat /proc/14453/limits
Max open files            1024                1024                files

　　这里就看出问题来了，当前这个进程的最大打开文件数只有1024，不管哪个层面的设置都没有对其生效，由于是supervisor 管理的进程，所以联想到是否supervisor 对其进行了设置，查了官方文档信息的到了一个“minfds”参数，用于设置默认supervisor进程分配打开文件数，修改默认1024参数后重启supervisor

vim  /etc/supervisord.conf 
minfds=10240

再次查看进程的limits信息就变更了。
　　centos7使用系统级设置不能全部控制所有应用的设置，而这个被supervisor 控制的程序更显得绕了个坑出来，supervisor在Linux中用于程序的控制还是很广泛，也算是积累了个经验。

转载请注明：菜鸟运维网 » supervisor 默认进程最大打开文件数的坑