记一则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的端口自启脚本),以确保修改后的上限生效!

posted @ 2020-04-13 15:48  書劍飄零  阅读(294)  评论(0编辑  收藏