记一则ulimit上限引起的su、vnc等服务无响应、黑屏等故障

最近给一台服务器搭建系统时，遇到普通用户（非root）su无法切换用户，一直无响应；以及个别用户的vnc登录黑屏。

同时top查看实时进程，可以看到dbus-daemon一直挂起占用资源。

开始找原因

1、首先查了vnc部分，黑屏，然后strace 看到一直在select等待；

$ strace -f -F -p xxxx            //xxxx是vnc server的pid

vnc看来是被block住了，但是被什么挡住或者无法使用呢？

此时su 切换其他用户也要等待很长时间，或者一直卡住。

2、看一下top吧，是否有进程异常；

打开，果不其然，dbus-daemon CPU 100% ，而且是持续100%

dbus究竟怎么了？

$strace -f -F -p  dbus-daemon-pid   //利用strace看一下dbus进程究竟在干嘛；

没有block住，而是不停的打印一些出错信息：

信息是某个pid调用dbus，而dbus反馈错误，错误是(too many open files)

 

至此找到根本原因，进程最大文件打开数量达到了系统的上线。而这个上限则是在/etc/security/limits.conf文件中定义的，默认是1024。

怎么解决

1、首先可以用ulimit -n，查看用户进程级的能够打开文件句柄的数量，Centos默认是1024。

2、查看当前系统的打开文件描述符数

$ cat /proc/sys/fs/file-nr
5664        0        18640

其中第一个数表示当前系统已分配使用的打开文件描述符数，第二个数为分配后已释放的（目前已不再使用），第三个数等于/proc/sys/fs/file-max。

3、修改ulimit上限。

临时设置：

#通过ulimit -Sn设置最大打开文件描述符数的soft limit，注意soft limit必须小于hard limit
$ ulimit -Sn 160000

#同时设置soft limit和hard limit。对于非root用户只能设置比原来小的hard limit。
$ ulimit -n 180000

这里设置的是当前shell的当前用户的打开的最大限制，如果当前用户打开多个shell，则每个shell都能打开该最大值。(网上资料，持疑。)

永久设置：

#root权限下，在/etc/security/limits.conf中添加如下两行，表示所有用户最大打开文件描述符数的soft limit为102400，hard limit为104800。重启生效
* soft nofile 102400
* hard nofile 104800
#也可以同时设置soft/hard
* - nofile 104800

这里限制一个用户的所有shell能打开的最大数。(网上资料，持疑。)

注意：设置nofile的hard limit还有一点要注意的就是hard limit不能大于/proc/sys/fs/nr_open，假如hard limit大于nr_open，注销后将无法正常登录。

4、ulimit -a/n/H/S 都有什么含义

ulimit -a 显示当前所有的资源限制

ulimit -H 设置硬件资源限制

ulimit -S 设置软件资源限制

ulimit -n 设置进程最大打开文件描述符数

ulimit -u <程序数目> 　用户最多可开启的程序数目

注意事项

若ulimit命令以及limit.conf文件的修改未生效，此时则需要重启messagebus服务。

service messagebus restart

甚至于可以把 service messagebus restart 写入开机脚本（比如vnc的端口自启脚本），以确保修改后的上限生效！