墨墨导读:本文来自墨天轮用户“你好我是李白”的投稿,使用root用户切换grid用户时报错-bash: fork: retry: Resource temporarily unava,这里记录故障处理全过程。墨天轮主页:https://www.modb.pro/u/3997
某日,朋友跟我讨论他巡检oracle数据库时遇到的一个情况,在使用root用户切换grid用户时报错-bash: fork: retry: Resource temporarily unavailable,一般这个报错都是因为/etc/security/limits.conf或/etc/security/limits.d/下相关用户nproc设置过小导致,但是定位一波三折,最终了解清楚了nproc参数生成、限制,将案例详细分享,供大家参考。
故障背景
巡检su – grid无法完成切换,报错
-bash: fork: retry: Resource temporarily unavailable。
环境介绍
操作系统为Redhat 6.8,数据库版本为Oracle 11.2.0.4 RAC。
初步分析,获取已存在进程limits环境设置
根据经验,上述报错一般为下面三个原因:
用户的nproc达到限制,无法创建新的进程
系统没有可分配的的pid,即进程号已经达到内核参数kernel.pid_max的限制
系统可用内存低,新的进程无法申请到内存导致不能启动
下面我们一步一步排查:
检查用户已经存在进程limits设置与用户ulimit设置,检查如下:
如果已经有会话登陆grid用户,可以通过下面命令得到当前限制
如果已经无法正确切换grid用户,可以使用如下步骤得到限制
第一步:获取grid用户任意进程pid
第二步:使用cat查看/proc//limits获取限制设置
可以看到上述无论是已经登陆grid还是真实进程设置均为16384,设置均不算过低,grid用户一般不会占用这么多的process,那到底是由于bug还是其他原因耗尽了设置呢还是内存或其他原因?
进一步分析,寻找limits.conf未生效原因
经过初步分析,初步判断并非设置过小导致,16384设置并不算小,RHEL默认/etc/sysctl.conf中内核参数kernel.pid_max为32768也足够使用,那接下来需要排查如下:
/etc/security/limits.conf与/etc/security/limits.d是否设置过低 ?
是否/etc/profile、/etc/profile.d/、/etc/bashrc、家目录下.bashrc、.bash_profile是否有相关ulimit配置脚本设置nproc设置过低 ?
是否grid用户下真有超过16384 process占用导致无法su – grid ?
是否有进程real user不属于grid但是effective user为grid消耗了grid所有进程数?
接下来我们继续一步一步排查
经过排查,/etc/security/limits.conf设置如下:
可以看到limits.