Bootstrapping SAS Services on Linux (RHEL 8)

SAS 9.4 installs on any Unix/Linux system provide a script which could be run to generate bootstrap ready scripts which could then be set to stop or start SAS services when a SAS (Nix) server is stopped or started. This is in addition to the default .../config/Lev1/sas.servers (and additional sas.servers.pre, sas.servers.mid) server scripts which are used to start|stop|restart|Status) SAS services.

This generate_boot_scripts.sh script is also located at .../config/Lev1. On of the key difference is that unlike sas.servers <option> which is executed by the sas installer ID, this script is executed as root, and as root bootstrapped. It is recommended that before generating the generate_boot_scripts.sh as root (which produces sas.servers, sas.servers.pre, and sas.servers.mid) backup the original sas.servers, sas.servers.pre, and sas.servers.mid scripts as the sas installed ID. Step suggested below:

as installer ID:

cd to .../config/Lev1

cp -p ./sas.servers  ./sas.servers.ORIG            #repeat for sas.servers.pre & sas.servers.mid

Once generate_boot_scripts.sh is executed, typically, sas.servers should be enough to bootstrap. The other two sas.servers.mid or sas.servers.pre are mostly for the situations where the SAS administrator wants to specifically control which portion of the SAS services to stop or start. Example would be, if the sas web applications require a restart for whatever reason, an admin does not need to stop all services; sas.servers.mid <start|stop|status|restart> would be used. Recommendation is to use sas.servers to bootstrap.

Executing generate_boot_scripts.sh will not process those services that are inactive. Ensure that all required SAS services are running before executing the generate script. Those services that are kept as inactive/stopped, for example, DeploymentTester the generate_boot_scripts.sh will issue a warning that the said service was not processed in the new set of sas.servers script. This is acceptable since we keep this service off by design and enable it for when specific need arises such as add/drop of a SAS module or post hot fixes or when SAS platform as a whole requires validation. Another such service is SAS Remote Service; provided for legacy applications.

Once new generate_boot_scripts.sh is generated, review permissions of the sas.servers* files, your ORIG should still be owned by SAS installer ID, while the new scripts owned by Root. Once you have bootstrapped sas.servers, you may change ownership of the new sas.servers* back to sas installer ID and ensure appropriate permissions are in effect.

chmod 755

chown sas:<sas group>

For manual status check, you may use the new sas.servers* Also if you are manually starting or stopping (there may be instances after hot fix patching) where you do not want the whole server to bounce, it is most advisable to use the sas installer ID, hence recommendation to revert back to original permissions and ownership after bootstrapping is done.