systemctl方式开机启动进程文件句柄数问题

现网近期发现一台业务主机进程频繁挂掉，然后会被watchdog自动拉起，运行一小段时间后又挂掉，不断重新启动，排查日志发现"Too many open files" ，打开文件数量超过文件句柄数了。

使用ulimit -a检查，配置的open files数量为100万，查看/etc/system.conf里面的fs.file-max=999999，ulimit检查是单进程允许打开文件数，system.conf检查是操作系统允许打开的文件数，使用lsof查看打开的文件和进程情况，发现增长较快，进程启动后很快能涨到30万左右，然后没到100万的情况下就又报错重启了，对30万打开文件进行分析，发现有很多都是不同线程打开的同一个文件，这种情况其实只消耗一个open files，那就还远没有达到100万的限制，日志与实际情况不吻合。

求助组内操作系统专家，指出了当前使用lsof查看已使用的文件句柄和使用ulimit -a查看进程允许打开的文件的方式并非完全可靠的，正确的方式应该是通过cat /proc/pid/limits来查看进程允许文件句柄数，并使用ll /proc/pid/fd | wc -l 来统计进程当前已打开的文件数量，发现limits下面的Max open files配置Soft Limit是1024，而Hard Limit是4096，远小于100万，而通过ll /proc/pid/fd | wc -l 查看也正是在接近4096时日志报错，进程重启，问题清晰了。

但为何进程的最大文件句柄数是4096不是unlimit -a 查看的100万呢，和操作系统专家进一步分析，业务进程是通过watchdog拉起的，用同样的方式查看watchdog的配置，Hard Limit也是4096，查看watchdog启动时间是最近一周，因为watchdog是配置过开机启动的，随即检查了主机启动时间，发现主机本周重启过，而watchdog正是主机重启后被自动拉起的。

业务使用CentOS操作系统，并配置使用systemctl方式的开机启动，所以watchdog进程被自动拉起时应该是使用的/etc/systemd/system.conf中的配置而非unlimit -a查看到的配置，unlimit -a查看的实际是/etc/security/limit.conf中的配置，此处配置是针对shell的，如果crontab 定时任务通过shell去拉起watchdog，则文件句柄限制应该是100万，但是使用systemctl方式就与此100万的配置无关了，为验证猜想，执行cat /etc/systemd/system.conf | grep -i "open file"，果然得到DefaultLimitNOFILE=4096的配置，此时执行systemctl show xxxx.service | grep FILE 查看，果然得到LimitNOFILE=4096

解决方案：

1. 修改操作系统配置：sudo vi /etc/systemd/system.conf 改为100万，然后执行sudo systemctl daemon-reload重亲加载配置

2. 修改业务配置，sudo vi /etc/systemd/system/xxxx.service，添加LimitNOFILE=1000000，然后执行sudo systemctl daemon-reload重亲加载配置

疑问：

被watchdog拉起的业务进程需要和watchdog的limit一致吗，是什么机制？

 

备注： 

1. Soft Limit只作出警告，Hard Limit是实际限制

2. 系统总限制：/proc/sys/fs/file-max，也可以在system.conf中查看file-max，可以通过cat查看目前的值，echo来立刻修改

/proc/sys/fs/file-nr，只读，可以看到整个系统目前使用的文件句柄数量