ORA-27300: OS system dependent operation:fork failed with status: 11

ORA-27301: OS failure message: Resource temporarily unavailable

 

ORA-27302: failure occurred at: skgpspawn3

The processes and resources started by CRS (Grid Infrastructure) do not inherit the ulimit setting for “max user processes” from /etc/security/limits.conf setting (Doc ID 1594606.1)

This is happening due to bug 17301761 THE MAXIMUM PROCESS VALUE OF OHASD,BIN IS TOO SMALL IF THE CRS STARTS MANUALLY

1) Go to GI_HOME/bin
2) Make a backup of ohasd script file
3) In the ohasd script file, locate the following code:

Linux)
# MEMLOCK limit is for Bug 9136459
ulimit -l unlimited
if [ “$?” != “0” ]
then
$CLSECHO -p has -f crs -l -m 6021 “l” “unlimited”
fi
ulimit -c unlimited
if [ “$?” != “0” ]
then
$CLSECHO -p has -f crs -l -m 6021 “c” “unlimited”
fi

ulimit -n 65536
In the above code, insert the following line just before the line with “ulimit -n 65536”
ulimit -u 16384
4) Recycle CRS manually so that the ohasd will not use new ulimit setting for open files.
After the database is started, please issue “ps -ef | grep pmon” and get the pid of it.
Then, issue “cat /proc//limits | grep process” and find out if the Max process is set to 16384.
Setting the number of processes to 16384 should be enough for most servers since having 16384 processes normally mean the server to loaded very heavily.  using smaller number like 4096 or 8192 should also suffice for most users.
In addition to above, the ohasd template needs to be modified to insure that new ulimit setting persists even after a patch is applied.
1) Go to GI_HOME/crs/sbs
2) Make a backup of crswrap.sh.sbs
3) In crswrap.sh.sbs, insert the following line just before the line “# MEMLOCK limit is for Bug 9136459”
ulimit -u 16384
Finally, although the above setting is successfully used to increase the number of processes setting, please test this on the test server first before setting the ulimit on the production.