Page 1 of 3

ENABLING SOLARIS PROJECT SETTINGS FOR CRS [ID 435464.1]

Modified 09-MAY-2011

Type BULLETIN

Status PUBLISHED

In this Document
Purpose
Scope and Application
ENABLING SOLARIS PROJECT SETTINGS FOR CRS
Short Remark on CRS and multiple Solaris projects
References

Applies to:
Oracle Server - Enterprise Edition - Version: 10.1.0.5 and later [Release: 10.1 and later ]
Oracle Solaris on SPARC (64-bit)
Oracle Solaris on x86-64 (64-bit)
Oracle Clusterware (CRS) and patchsets 10.2.0.1 - 11.2.0.1
Sun Solaris Sparc and x86-64 (64-bit)

Purpose
This Note discusses options available to enable automatic start of CRS with Solaris 10 project settings.
Due to the CRS fixes available in CRS versions 11.2.0.2 this note ultimately applies only to
CRS versions not including a fix for bug 9442360 (bug id affecting 11.2.0.x CRS versions) or
bug 5629487 (bug id affecting 10.2.0.x - 11.1.0.x CRS versions).
If a fix for bug 5629487 or bug 9442360 is present in the CRS install then
this note can be ignored or read as informational.

Scope and Application

Please notice that both Sun Microsystems and Oracle still support the old method of
supplying these values for shared memory and semaphore parameters in /etc/system.
The various methods presented in this document are thus not explicitly recommended
although they have been verified to work.

ENABLING SOLARIS PROJECT SETTINGS FOR CRS

When enabling project settings for legacy type daemons

(i.e. in Solaris 10 terminology those daemons not managed as SMF services)
DBA's and System Administrators face difficulties to enable
Oracle required OS parameters like SHMMAX or SEMMNS
(this being the pre Solaris 9/10 and pre Solaris 10 Containers terminology)
through the newer project settings and enable project settings at boot time.
To enable project settings at boot time a basic difficulty arises
as Solaris 10 does not support any user defined projects for legacy_run daemons.
In order to overcome this difficulty two options exist:
1. change SYSTEM project settings which is active at boot time
2. use newtask -p <user project> command for the daemon needing
project settings or other means of changing the task project.
Solution 1: Change SYSTEM project settings
This still can be achieved in at least two ways:
A. Modify limits for the parameters of interest:
Example:
projmod -s -K "project.max-shm-memory=(privileged,2.00TB,deny)" system
projmod -s -K "project.max-sem-ids=(privileged,2048,deny)" system
I.e. /etc/project would look like:
system:0::::project.max-sem-ids=(privileged,2048,deny);project.max-shm-memory=
(privileged,2199023255552,deny)
user.oracle:100::::project.max-sem-ids=(privileged,2048,deny);project.max-shm-memory=
(privileged,2199023255552,deny)
The last entry is needed for the Oracle user to startup instances when connecting directly
with sqlplus in an user session while the first line for system project is needed by the boot
time CRSD database startup or by manual srvctl startup.
This method is not supported due to the problems described in below section:

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=435464.1

11/26/2011

Page 2 of 3

"Problems which might be encountered when implementing Solution 1A"

B. Instead of changing /etc/project (and /etc/user_attr as per below problem section)
dynamic changes of system project through prctl command can be added in an own
rc script:
prctl -n project.max-shm-memory -v <value needed> -r -i project system
prctl -n project.max-sem-ids -v <value needed> -r -i project system
This own rc script would need to be executed before the rc3.d/S96init.crs would be executed
and also an entry like "system:0::::" needs to exist in /etc/project for this solution to work.
Example: /etc/rc3.d/S91proj:
#!/bin/sh
prctl -n project.max-shm-memory -v 2.2TB -r -i project system
prctl -n project.max-sem-ids -v 2048 -r -i project system
Solution 2: Assigning process to a different task and project
This as well can be achieved in different ways but basically the CRSD daemon needs
to receive the new project settings.
A. either by editting the init.crsd script and adding a line like:
newtask -p <user_project> -c $$
or
newtask -p <user_project> $ORA_CRS_HOME/bin/crsd $BOOTFLAG $*
The latter is implemented by Oracle's fix for bug 5629487, which is included in CRS 11.1.0.7
so this method should be considered supported.
The fix for bug 5629487 needed more review for CRS 11gR2 and
so it has been addressed for 11.2.0.x versions under bug 9442360 and included in the 11.2.0.2 release.
B. Moving the CRS init scripts to SMF and adding to the new init.crsd service
<method_context
project='some_userdefined_crsproj' >
<method_credential
user='root' />
</method_context>
</exec_method>
This method is not supported either and shouldn't be used as long as CRS scripts are not yet integrated into SMF.
Verification of project settings taking effect
For Solution 1 to verify the system project settings were altered after
issuing the above projmod command the following prctl command for the init
process can be run:
prctl -n project.max-shm-memory 1
which would need to show a line:
privileged 2.00TB - deny -

Problems which might be encountered when implementing Solution 1A

It was reported that implementing Solution 1A was not allowing to startup the
database service automatically at boot time of CRS.
Some tests showed that adding project=system to /etc/users_attr for user root was
at least allowing to startup manually the database through srvctl command.
I.e. /etc/user_attr needed to look like:
root::::auths=solaris.*,solaris.grant;profiles=Web Console
Management,All;lock_after_retries=no;project=system
After more research this was found to happen due to Solaris CR#5000940:
Synopsis: project 0's rctls are not applied from /etc/project
Another observed side effect is that if someone logins to the server before CRS started up
then automatic startup of the database might succeed.
This too is included in the description of Solaris CR#5000940.

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=435464.1

11/26/2011

Page 3 of 3

As per Solaris CR#5000940 the best way to avoid the problem is to execute a command like:
newtask -p system /usr/bin/true
before CRS startup, i.e. creating an rc script /etc/rc3.d/S91proj:
#!/bin/sh
#
# see http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5000940
# why this is needed
#
newtask -p system /usr/bin/true
would resolve these issues.
To summarize for Solution 1A to work these changes are needed:
/etc/project needs to have system project modified as in above example,
/etc/user_attr does not need to be modifed and
a script needs to be created (e.g. /etc/rc3.d/S91proj) containing
the command "newtask -p system /usr/bin/true"

Short Remark on CRS and multiple Solaris projects

The current design of CRS/GRID is to support only the CRS/GRID install user's project to be enabled for the
database instances
which are automatically started as CRS resources. Unlike when starting up an instance in an user session and
enabling whichever project might be
desired the same is currently not possible in CRS/GRID.
This statement refers to all current versions, patchset and PSU releases of CRS and GRID,
i.e. 10.2.0.1.0 - 11.2.0.2.x

References
BUG:5629487 - WRONG RESOURCE CONTROL PROJECT SELECTED WHEN STARTING DATABASE USING
SRVCTL
NOTE:429191.1 - Kernel setup for Solaris 10 using project files.
NOTE:603051.1 - SRVCTL FAILS TO START DATABASE WHILE SQLPLUS WORKS
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=5000940

Related

Products
Oracle Database Products > Oracle Database > Oracle Database > Oracle Server - Enterprise Edition
Keywords
CRS-215; ORA-27102; PRKP-1001; SOLARIS; SRVCTL

Back to top
Copyright (c) 2007, 2010, Oracle. All rights reserved. Legal Notices and Terms of Use | Privacy Statement

https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=435464.1

11/26/2011