问题描述
现场反馈vertica库不能访问了，就登录服务器查看，发现su - dbadmin切换dbadmin用户时提示如下报错：
[root@dshuju02 ~]# su - dbadmin
Last login: Mon Jun 30 10:18:41 CST 2025 on pts/4
su: failed to execute /bin/bash: Too many open files in system别被报错带偏哈，这次可不是最大文件数值小导致的。
分析过程
查看当前系统设置的最大句柄数
too many open files(打开的文件过多)是Linux系统中常见的错误，从字面意思上看就是说程序打开的文件数过多，不过这里的files不单是文件的意思，也包括打开的通讯链接(比如socket)，正在监听的端口等等，所以有时候也可以叫做句柄(handle)，这个错误通常也可以叫做句柄数超出系统限制。
引起的原因就是进程在某个时刻打开了超过系统限制的文件数量以及通讯链接数。
--查看当前系统设置的最大句柄数
[root@dshuju02 ~]# ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 514944
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 514944
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimitedopen files那一行就代表系统目前允许单个进程打开的最大句柄数，这里是1024。
列出所有正在运行的java进程
[root@dshuju02 ~]# jps #注意每次查询的进程号都不相同，导致下面统计单个进程打开文件数量是0
255626 Jps
lsof -p 255805 | wc -l
[root@dshuju02 ~]# lsof -p 255626 | wc -l
0统计进程打开了多少文件
总文件数太大了
[root@dshuju02 ~]# lsof | wc -l
3337215查看inode是否用尽
inode才使用2%，排除该因素。
查看操作系统日志
vi /var/log/messages
从2025-6-30号就反复输出图片报错，和现场沟通这是什么应用，也回答不清楚
解决办法
增加最大句柄数值(未解决问题)
修改系统配置文件
正值业务使用期间，不敢随意让云上重启服务器，担心服务器出现重启失败现象，所以修改系统配置文件后未重启操作系统。
vim /etc/security/limits.conf
#在最后加入
* soft nofile 4096
* hard nofile 4096 临时增加最大句柄数值
把当前用户的最大允许打开文件数量设置为2048了，但这种设置方法在重启后会还原为默认值。
注意：ulimit -n命令非root用户只能设置到4096，想要设置到8192需要sudo权限或者root用户。
ulimit -n 65536再次su - dbadmin依然提示以下报错：
[root@dshuju02 ~]# su - dbadmin
Last login: Mon Jun 30 10:18:41 CST 2025 on pts/4
su: failed to execute /bin/bash: Too many open files in system停止CDMClient进程相关的服务
查询并干掉CDMClient进程相关的服务
和现场多次确认CDMClient应用不是项目中使用的，恢复业务为先，征得负责人同意后可以干掉该应用。
[root@dshuju02 ~]# ps -ef | grep CDMClient
root 86671 1 0 Jun30 ? 00:00:10 /opt/CDMClient/HWClientService/BasicRunner/esfdaemon -df /opt/CDMClient/etc/ClientService/BasicRunner/clientsvc.config
root 86684 86671 0 Jun30 ? 00:01:39 /opt/CDMClient/HWClientService/BasicRunner/agentproc --fdPipe1Write=7 --fdPipe1Read=6 --fdPipe2Read=8 --fdPipe2Write=9 --user=root
root 86752 1 0 Jun30 ? 00:01:23 /opt/CDMClient/HWClientService/AggregateApp/esfdaemon -df /opt/CDMClient/etc/ClientService/AggregateApp/clientsvc.config
root 86801 1 0 Jun30 ? 00:01:21 /opt/CDMClient/HWClientService/XenServer/esfdaemon -df /opt/CDMClient/etc/ClientService/XenServer/clientsvc.config
root 258014 256213 0 10:14 pts/1 00:00:00 grep --color=auto CDMClient
root 417713 1 0 Apr29 ? 02:19:21 /opt/CDMClient/HWClientService/AggregateApp/eefproc --cluster=10.254.20.2 --code=FYK1YQMHOW5Z6TBE --cpuquota= --detect=300 --execid=dcd40e8924f911f09bf48c2a8e947ce6 --local=172.19.106.163 --port=9573 --servicetype=47 --severip=10.254.20.14 --type=1001干掉以上进程
kill -9 86671
kill -9 86684
kill -9 86752
kill -9 86801
kill -9 417713再次查询总文件数，多次查询静止在4615
[root@dshuju02 ~]# lsof | wc -l
4615su - dbadmin切换成功并启动数据库，业务访问数据库恢复。
总结
CDMClient根据进程查询推测是华为云迁移组件，最后通过现场和云上沟通确实是，云上说可以给卸载到，本着谁安装谁卸载的规则云上进行卸载。常规解决办法解决不了问题时可以尝试猜测着解决，比如没想到一应用会触发Too many open files in system报错。
