How to Start GI after the init. ohasd and ohasd files in the oracle etc directory are lost

We already know that/etc/init. d/init. ohasd in 11.2 and 12c RAC is the daemon process for starting all other processes of RAC.
So what if someone accidentally deleted the file or modified it by mistake?
This solution is not difficult, because in the Standalone environment,/etc/init. d/init. ohasd comes from $ GRID_HOME/crs/init. ohasd, and/etc/init. d/ohasd comes from $ GRID_HOME/crs/init/ohasd.
[Root @ lunarlib etc] # env | grep ORA
ORACLE_SID = + ASM
GRID_HOME =/u01/app/11.2.0.4/grid
[Root @ lunarlib rootwork] # ls-lrt $ GRID_HOME/crs/init
Total 28
-Rw-r -- 1 root 6721 Oct 11 0:30 ohasd
-Rw-r -- 1 root 8794 Oct 11 0:30 init. ohasd
-Rw-r -- 1 root 7038 Oct 11 0:30 ohasd. sles
[Root @ lunarlib rootwork] #
Compare ohasd and init. ohasd under $ GRID_HOME/crs/init/and/etc/init. d/to see if the file content is consistent:
[/Shell]
[Root @ lunarlib rootwork] # ls-lrt $ GRID_HOME/crs/init/ohasd
-Rw-r -- 1 root 6721 Oct 11 0:30/u01/app/11.2.0.4/grid/crs/init/ohasd
[Root @ lunarlib rootwork] # ls-lrt/etc/init. d/ohasd
-Rwxr-x --- 1 root 6721 Oct 11 0:30/etc/init. d/ohasd
[Root @ lunarlib rootwork] # ls-lrt $ GRID_HOME/crs/init. ohasd
-Rw-r -- 1 root 8794 Oct 11 0:30/u01/app/11.2.0.4/grid/crs/init. ohasd
[Root @ lunarlib rootwork] # ls-lrt/etc/init. d/init. ohasd
-Rwxr-x --- 1 root 8794 Jan 11 :56/etc/init. d/init. ohasd
[Root @ lunarlib rootwork] #
[Root @ lunarlib rootwork] # diff $ GRID_HOME/crs/init/ohasd/etc/init. d/ohasd
[Root @ lunarlib rootwork] # diff $ GRID_HOME/crs/init. ohasd/etc/init. d/init. ohasd
[Root @ lunarlib rootwork] #
As you can see, the content in the $ GRID_HOME/crs/init/and/etc/init. d/directories is consistent, but the permissions are different. The file permission in the/etc/init. d/directory is 750, and that in $ GRID_HOME/crs/init is 644.
Okay, the solution is available. If/etc/init. d/init. ohasd or/etc/init. d/ohasd lost. Manually create/etc/init. d/init. ohasd:
Cp $ GRID_HOME/crs/init. ohasd/etc/init. d/init. ohasd
Chmod 750/etc/init. d/init. ohasd
If you are more careful, we will find that in addition to the two files in the $ GRID_HOME/crs/init Directory, there is also a file named ohasd. sles.
A friend familiar with SLES Linux may have guessed that, yes, this is the ohasd version used on SLES Linux.
Check whether the current version is SLES:
[Root @ lunarlib rootwork] # rpm-q sles-release
Package sles-release is not installed
[Root @ lunarlib rootwork] #
Now, we delete the/etc/init. d/init. ohasd file to simulate the loss or damage of the init. ohasd file:
[Root @ lunarlib rootwork] # rm-f/etc/init. d/init. ohasd
[Root @ lunarlib rootwork] #
Copy the file $ GRID_HOME/crs/init/and start it manually:
The following shows the results of reboot after/etc/init. d/init. ohasd is deleted (you can also use the kill process without restarting the host ):
[Root @ lunarlib rootwork] # ps-ef | grep-v grep | grep ohasd
[Root @ lunarlib rootwork] # ps-ef | grep-v grep | grep-E 'init | d. bin | ocls | evmlogger | uid'
UID PID PPID C STIME TTY TIME CMD
Root 1 0 0 09:37? 00:00:00/sbin/init
[Root @ lunarlib rootwork] #
We can see that no RAC process is started currently.
We try to restore the lost ohasd daemon configuration file:
[Root @ lunarlib rootwork] # cp $ GRID_HOME/crs/init. ohasd/etc/init. d/init. ohasd
Cp: overwrite '/etc/init. d/init. Ohasd '? Y
[Root @ lunarlib rootwork] #
Then, after the reboot system, the process has been started:
[Root @ lunarlib rootwork] # ps-ef | grep-v grep | grep ohasd
Root 2882 1 0 :33? 00:00:00/bin/sh/etc/init. d/init. ohasd run
[Root @ lunarlib rootwork] # ps-ef | grep-v grep | grep-E 'init | d. bin | ocls | evmlogger | uid'
UID PID PPID C STIME TTY TIME CMD
Root 1 0 0 :32? 00:00:00/sbin/init
Root 2882 1 0 :33? 00:00:00/bin/sh/etc/init. d/init. ohasd run
[Root @ lunarlib rootwork] #
[Root @ lunarlib rootwork] #/sbin/initctl list | grep oracle-ohasd
Oracle-ohasd start/running, process 2882
[Root @ lunarlib rootwork] #