Description & Scope
Have SAP including AnyDB start when the operating system starts and then stop properly when the operating system stops.
Applies to not only the Web Application Server ABAP or Java, and databases such as MaxDB and Oracle, but also to the Content Server and SAProuter, etc.
Work with and around the SAP-delivered sapinit, which is installed with the host agent and outputs these messages upon operating system startup and shutdown:
Starting SAP Services ............................................. OK
Stopping SAP Services ........................................... OK
Start database services before sapinit and start application services after sapinit and then stop application services before sapinit and stop database services after sapinit:
Starting database services ........................................ OK Starting SAP Services ............................................. OK Starting application services ..................................... OK
Stopping application services ................................... OK Stopping SAP Services ........................................... OK Stopping database services ...................................... OK
- Root access
- Access to the console log to validate the messages shown during startup and shutdown.
- May require access to the partition console, iLO, or management processor.
- With regard to the database listener and the database instance, knowledge of what needs to be handled as part of “database services” and what will be handled as part of “application services.”
- If the database instance will be started as part of the application startup because the deprecated ‘startsap’ command will be used, then only the database listener needs to be started as part of the database services startup.
- If the SAP instance will be started using the newer ‘sapstartsrv’ and also ‘startsap db’ will not be used, then both the database listener and instance will need to be started as part of database services.
- Which commands will be used to handle the database listener, database instance, and application, and as which UNIX user for each.
- If the database instance startup requires user authentication beyond the operating system user authentication, set up for being able to start the database instance without needing to enter a password each time.
- For example, for MaxDB for the Content Server, the MaxDB XUSER key needs to be configured as manual step.
Create a configuration file /etc/rc.config.d/app:
# Application configuration # # APP: If set to 1, application services will be started. # APP=0 APP_OS_USER="" APP_START_CMD="" APP_STOP_CMD=""
Create a configuration file /etc/rc.config.d/db:
# Database configuration # # DB: If set to 1, database services will be started. # DB=0 DB_OS_USER="" DB_START_CMD="" DB_STOP_CMD=""
The variable defined in these two config files will be used in the new scripts.
Next, use copies of the /sbin/init.d/template file provided with HP-UX as the starting point for new scripts /sbin/init.d/app and /sbin/init.d/db.
Set appropriate permissions and ownership on the new scripts as compared to the existing other scripts there–mainly make sure the new scripts are executable.
Changes for /sbin/init.d/app:
*** /sbin/init.d/template Thu Feb 15 13:35:29 2007 --- /sbin/init.d/app ... *************** *** 10,16 **** # is unbootable. Do not modify this script. # ! # <Insert comment about your script here> # # Allowed exit values: --- 10,16 ---- # is unbootable. Do not modify this script. # ! # Start application services # # Allowed exit values: *************** *** 71,85 **** case $1 in 'start_msg') ! # Emit a _short_ message relating to running this script with ! # the "start" argument; this message appears as part of the checklist. ! echo "Starting the <specific> subsystem" ;; 'stop_msg') ! # Emit a _short_ message relating to running this script with ! # the "stop" argument; this message appears as part of the checklist. ! echo "Stopping the <specific> subsystem" ;; 'start') --- 71,81 ---- case $1 in 'start_msg') ! echo "Starting application services" ;; 'stop_msg') ! echo "Stopping application services" ;; 'start') *************** *** 92,103 **** fi # Check to see if this script is allowed to run... ! if [ "$CONTROL_VARIABLE" != 1 ]; then rval=2 else ! ! # Execute the commands to start your subsystem ! : fi ;; --- 88,97 ---- fi # Check to see if this script is allowed to run... ! if [ "$APP" != 1 ]; then rval=2 else ! /usr/bin/su - $APP_OS_USER -c "$APP_START_CMD" fi ;; *************** *** 110,121 **** fi # Check to see if this script is allowed to run... ! if [ "$CONTROL_VARIABLE" != 1 ]; then rval=2 else ! : ! # Execute the commands to stop your subsystem ! fi ;; --- 104,113 ---- fi # Check to see if this script is allowed to run... ! if [ "$APP" != 1 ]; then rval=2 else ! /usr/bin/su - $APP_OS_USER -c "$APP_STOP_CMD" fi ;;
For /sbin/init.d/db, here are just the changed lines:
# Start database services echo "Starting database services" echo "Stopping database services" if [ "$DB" != 1 ]; then /usr/bin/su - $DB_OS_USER -c "$DB_START_CMD" if [ "$DB" != 1 ]; then /usr/bin/su - $DB_OS_USER -c "$DB_STOP_CMD"
Create symbolic links to the new scripts:
ln -s /sbin/init.d/db /sbin/rc2.d/K110db ln -s /sbin/init.d/db /sbin/rc3.d/S900db ln -s /sbin/init.d/app /sbin/rc2.d/K100app ln -s /sbin/init.d/app /sbin/rc3.d/S910app
Go back and edit the two configuration files to set the UNIX user and the command.
Web Application Server (ABAP or Java) on Oracle, traditional startup, for the primary application server instance with the database on the same server, and where the user ‘oracle’ has been adopted as the main UNIX user for Oracle
APP_OS_USER=sidadm APP_START_CMD="startsap" APP_STOP_CMD="stopsap"
DB_OS_USER=oracle DB_START_CMD="lsnrctl start" DB_STOP_CMD="lsnrctl stop"
Content Server with local MaxDB as the document storage
APP_OS_USER=sapcs APP_START_CMD="apa22/bin/apachectl start" APP_STOP_CMD="apa22/bin/apachectl stop"
DB_OS_USER=sqddbsid DB_START_CMD="sdbgloballistener start; dbmcli -U DEFAULT db_online" DB_STOP_CMD="dbmcli -U DEFAULT db_offline; sdbgloballistener -all stop"
SAProuter, standalone with no other SAP instance or database on the same host
APP=1 APP_OS_USER=sidadm APP_START_CMD="/path/to/wrapper_script_to_start_saprouter_with_options" APP_STOP_CMD="/path/to/saprouter -s"
Where the wrapper script starts it in the background to allow the user session to exit so our init script can exit:
cd /path/to/dir_for_saprouter; nohup /path/to/saprouter ...options... &
When ready to enable all this, change the variables in the two configuration files from 0 to 1.
When one of the scripts is not needed, such as in the SAProuter example, leave the variable set to 0 in the respective configuration file.
As root, run each script in the correct order with the correct argument, verifying that in between, everything is started or stopped properly as expected.
This is assuming that at this point everything is currently running:
If that worked, do an operating system restart to further exercise it.
After the operating system is back up:
Review the console log to verify the messages shown in the Overview & Scope.
Review the contents of /etc/rc.log.old for the shutdown and /etc/rc.log for the startup. Search for the sections beginning with the same messages.
In reviewing /etc/rc.log and /etc/rc.log.old there may be extraneous characters present that are a side-effect of using su to sidadm, etc. but not having a terminal during the OS startup and shutdown.
This does not apply to starting the diagnostic agent, which is started by sapinit after being configured in /usr/sap/sapservices.
To fully verify the database portion, review the database log for a complete shutdown and a normal startup. For example, for Oracle, review the alert log to confirm that the database was closed normally and that upon startup, an instance recovery was not required,which would indicate an improper shutdown.
For the Content Server with MaxDB, the MaxDB listener is not technically required for the Content Server when the Content Server and MaxDB are on the same host, however the listener is needed for monitoring such as with Solution Manager or for remote database administration.
For SAProuter standalone, where there is no SID, make up a sidadm user such as srtadm and use that for running the SAProuter.
In recent HP-UX releases a symbolic link has been added with a number that places an unrelated script in the midst of the scripts here. Ignore this:
Configuring SCSI Subsystem ........................................ OK
Using generic scripts and configuration files with generic names ‘app’ and ‘db’ and generic terms “database services” and “application services” so that can be used for various AnyDB and SAP products and so that the files including the symbolic links can be in included in your base operating environment build. On a given host, only the variables in the config files needed to be customized.
The alternative is to have scripts, configuration files, and variables like oracle, ORACLE, and messages like “Starting Oracle” appearing in the OS startup.
The reason for the specific numbers and names in the symbolic link names is to place the execution of the scripts as desired before or after the execution of sapinit. S910app will be started after the SAP-delivered S900sapinit due to 910 being greater and S900db will start before S900sapinit due to the sorting involved with ‘d…’ before ‘s…” and upon shutdown the situation is reversed.
One scenario is that sapinit or the host agent, which sapinit starts, may be able to be configured to start the SAP instance, making the ‘app’ script unnecessary, but the ‘db’ script will still need upon startup to run before sapinit in order to start the database and listener.
For SAProuter, one reason for the wrapper script for the startup is because the list of options may make the command unwieldly for the rc config file if you have several options listed for configuring logging, etc. so placing the options in the wrapper script rather than in the rc script.