Note#
=======
From 10.1.0.4
===============================
/etc/init.d/init.crs start
/etc/init.d/init.crs stop
/etc/init.d/init.crs enable
/etc/init.d/init.crs disable
starts crsd,cssd,evmd daemons.
From 10.2.X
===============================
crsctl stop crs
crsctl start crs
crsctl enable crs
crsctl disable crs
The startup of the Oracle clusterware daemons is based on start scripts that are executed as root user.
The environment variables are set in these scripts.
The clusterware start scripts can be found in:
· /etc/init.d (Sun, Linux)
· /sbin (HPUX, HP Itanium, Tru64)
· /etc (AIX)
They are named:
· init.cssd: starts ocssd.bin, oclsomon, oprocd and oclsvmon daemons
· init.evmd: starts evmd.bin daemon
. init.crsd: starts crsd.bin daemon
· init.crs : enabler/start/disabler script
Automatic startup of the clusterware daemons rely on these 3 steps (two Unix OS system mechanisms and a check of whether the clusterware is startable.
1. Execution of the init.d rc*.d scripts that enable the clusterware to start or not after a reboot
Note: The init.* scripts should never normally be run from the command line, if you do require manual disabling or enabling of CRS startup other than for the diagnostic purposes listed in this note then invoke crsctl as the root user as follows:
$ crsctl disable crs
Oracle Clusterware is disabled for start-up after a reboot.
$ crsctl enable crs
Oracle Clusterware is enabled for start-up after a reboot.
Running 'init.crs enable' allows the clusterware to autostart at system reboot ( this is the default
setting).
Running 'init.crs disable' (does the reverse) prevents the clusterware from autostarting at system reboot.
When the rc*.d scripts are executed at the correct OS runlevel, then the 'init.crs start' execution
(executed in run level 3 or 5 for the Unix versions) will check the automatic setting (enabled or
disabled) and set the clusterware in startable or non startable mode accordingly.
2. The inittab mechanism via the three respawnable clusterware scripts
A successful installation will populate the inittab file with entries to start the CRS stack:
3. The prerequisite check with the 'init.cssd startcheck' execution
The clusterware scripts further run a check script to know whether the clusterware is startable before launching the clusterware processes, that is, to check whether basic prerequisites are met and permit the clusterware to start :
init.cssd startcheck
That last script needs to return code 0 to permit the clusterware to start. In case of errors
/tmp/crsctl.xxxx logging files are written with the error message.
It executes as user oracle this command via a
'su -l oracle'
crsctl check boot
Execution of this command should return nothing in order to permit the clusterware to start.
Note: 'crsctl check boot' may return other errors such as:
'no read access to the ocr', 'clustered ip is not defined' or '$CRS_HOME is not mounted'
and prevent the clusterware from starting.
Once the above three prerequisites are met, the clusterware starts via *.bin executables which can be confirmed using the command:
'ps -ef grep .bin':
oracle 19611 19610 0 Dec17 /opt/app/oracle/product/crs/bin/oclsomon.bin
oracle 19547 18245 0 Dec17 /opt/app/oracle/product/crs/bin/ocssd.bin
oracle 18215 18005 0 Dec17 /opt/app/oracle/product/crs/bin/evmd.bin
root 18649 16555 0 Dec17 /opt/app/oracle/product/crs/bin/crsd.bin
