01 May Quick Tip : oracle user ulimit doesn’t reflect value on /etc/security/limits.conf
So the other day I was trying to do a fresh installation of a new Oracle EM12cR4 in a local VM, and as I was doing it with the DB 12c, I decided to use the Oracle preinstall RPM to ease my installation of the OMS repository database
[root@em12cr4 ~]# yum install oracle-rdbms-server-12cR1-preinstall -y
I was able to install the DB without any issues, but when I was trying to do the installation of EM12cR4, an error in the pre-requisites popped up
WARNING: Limit of open file descriptors is found to be 1024.
For proper functioning of OMS, please set “ulimit -n” to be at least 4096.
And if I checked the soft limit for the user processes , it was set to 1024
[email protected] [emrep] ulimit -n
1024
So if you have been working with Oracle DBs for a while you know that this has to be checked and modified in/etc/security/limits.conf , but it was my surprise that the limit has been set correctly for the oracle user to at least 4096
[root@em12cr4 ~]# cat /etc/security/limits.conf | grep -v "#" | grep nofile
oracle soft nofile 4096
oracle hard nofile 65536
So my next train of thought was to verify the user bash profile settings , as if the ulimits are set there, it can override the limits.conf, but again it was my surprise that there was nothing in there, and that is were I was perplexed
[oracle@em12cr4 ~]# cat .bash_profile
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
PATH=$PATH:$HOME/bin
export PATH
So what I did next was open a root terminal and do a trace of the login of the oracle user
[root@em12cr4 ~]# strace -o loglimit su - oracle
And in another terminal was verify what was the user reading regarding the user limits, and this is where I hit the jackpot, I was able to see here that it was reading the pam_limits.so and the /etc/security/limits.conf as it should, but it was also reading another configuration file called oracle-rdbms-server-12cR1-preinstall.conf, does this look familiar to you 🙂 , and as you can see the RLIMIT_NOFILE was being set to 1024 .
[root@em12cr4 ~]# grep "limit" loglimit
getrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=32768*1024}) = 0
open("/lib64/security/pam_limits.so", O_RDONLY) = 6
...
open("/etc/security/limits.conf", O_RDONLY) = 3
read(3, "# /etc/security/limits.conf\n#\n#E"..., 4096) = 2011
open("/etc/security/limits.d", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
open("/etc/security/limits.d/90-nproc.conf", O_RDONLY) = 3
read(3, "# Default limit for number of us"..., 4096) = 208
open("/etc/security/limits.d/oracle-rdbms-server-12cR1-preinstall.conf", O_RDONLY) = 3
setrlimit(RLIMIT_STACK, {rlim_cur=10240*1024, rlim_max=32768*1024}) = 0
setrlimit(RLIMIT_NPROC, {rlim_cur=16*1024, rlim_max=16*1024}) = 0
setrlimit(RLIMIT_NOFILE, {rlim_cur=1024, rlim_max=64*1024}) = 0
So I went ahead and checked the file /etc/security/limits.d/oracle-rdbms-server-12cR1-preinstall.conf and evidently, that is where the limit was set to 1024, so the only thing I did was change the value there to 4096.
[root@em12cr4 ~]# cat /etc/security/limits.d/oracle-rdbms-server-12cR1-preinstall.conf | grep -v"#" | grep nofile
oracle soft nofile 1024
oracle hard nofile 65536
[root@em12cr4 ~]# vi /etc/security/limits.d/oracle-rdbms-server-12cR1-preinstall.conf
[root@em12cr4 ~]# cat /etc/security/limits.d/oracle-rdbms-server-12cR1-preinstall.conf | grep -v"#" | grep nofile
oracle soft nofile 4096
oracle hard nofile 65536
Once I did that change, and logged out and logged back in, I was able to see the values that I had set in the first place in /etc/security/limits.conf and now I was able to proceed with the installation of EM12cR4
[email protected] [emrep] ulimit -n
4096
Conclusion
So when you install the RPM oracle-rdbms-server-12cR1-preinstall, be sure that if you are to change any future user limits, there might be another configuration file that can be setting other values than the ones desired and set in /etc/security/limits.conf
Sorry, the comment form is closed at this time.