Using systemd to Start/Stop SAP services on SUSE Linux

[former_member44112]

Background

Being managing SAP landscapes hitherto on SUSE Linux 12 on public cloud (IaaS) environments, the de facto way to start/stop SAP database and NetWeaver services as a part of system boot/shutdown has been via leveraging /etc/init.d/after.local (for startup of SAP services) and /etc/init.d/halt.local (for shutdown of SAP services). However, having recently performed a fresh installation of an SAP product on SUSE Enterprise Linux 15 (SLES 15), I realised it is no more possible to leverage the after.local and halt.local capabilities. These configuration files are part of Linux SystemV init configuration and work fine up until SLES 12, but with SLES 15 these do not work.

Introduced with SLES 12, systemd is the new system startup and service manager for Linux, which replaces the old SystemV init (SysV init). However, SLES 12 does retain the older after.local and halt.local capability to start/stop services. From onwards SLES 15, it is mandatorily required to use systemd to create services that can be executed at boot-up or before a system shutdown and after.local or halt.local files are not provided.

This post is not intended to provide detailed insights into the functioning of the systemd daemon but aims to illustrate how can it be used to start/stop SAP services on a server startup/shutdown.

Defining systemd service for SAP

A standard way to describe services in system is via unit files. To define a new system service, it is required to create a unit file for the service under /usr/lib/systemd/system. Once the desired service’s unit file is created, it is required to create a symbolic link for the unit file under /etc/system/system and then enable the service.

Following is a sample unit file for a service defined to start/stop SAP services upon system startup or shutdown.

sapgts:/usr/lib/systemd/system # ls -ltr sapgts.service

-rw-r--r-- 1 root root 349 Jul 10 03:46 sapgts.service

sapgts:/usr/lib/systemd/system # cat sapgts.service

[Unit]

Description=SAP GTS Startup and Shutdown Service

After=sapconf.service network.target



[Service]

Type=simple

RemainAfterExit=yes

ExecStart=/bin/bash /root/start_gts.sh

ExecStop=/bin/bash /root/stop_gts.sh

TimeoutStartSec=8min

TimeoutStopSec=8min

TimeoutStartFailureMode=abort

TimeoutStopFailureMode=abort

[Install]

WantedBy=multi-user.target

sapgts:/usr/lib/systemd/system #

In the above unit file, Description directive is a cleartext description of the service that is being defined while the After directive drives what services should the current newly defined service should start after. In the case of the above unit file, we are defining that the sapgts service (to start SAP GTS database and application services) should start after the sapconf.service and network.target services are started.

sapconf service is a standard service offered by SLES 15 and SLES 15 for SAP Linux distributions and is a replacement of sapconf/tuned command that was offered with SLES 11 / SLES 11 for SAP and SLES 12 / SLES 12 for SAP distributions). sapconf is aimed at rolling up the various SAP specific tuning configurations and parameters that are recommended for running SAP workloads on SUSE Linux Enterprise Server / SUSE Linux Enterprise Server for SAP distributions.

The ExecStart and ExecStop directives point to independent sapcontrol commands that you’d need to execute to start or stop SAP database and application services. In our case, the scripts are as follows:

/root/start_gts.sh

sapgts:~ # cat start_gts.sh

#!/bin/bash

echo '-----------------------------' >> /tmp/startup.log

echo `date` >> /tmp/startup.log

echo 'Starting HANA DB..' >> /tmp/startup.log

sudo su - gtdadm << EOF

     HDB start

EOF

echo 'After Starting HANA DB..' >> /tmp/startup.log

echo `date` >> /tmp/startup.log

echo 'Starting Application..' >> /tmp/startup.log

sudo su - gtaadm << EOF

     sapcontrol -nr 01 -function StartSystem ALL

     sapcontrol -nr 02 -function StartSystem ALL

EOF

echo `date` >> /tmp/startup.log

echo 'Started Application..' >> /tmp/startup.log

/root/stop_gts.sh

sapgts:~ # cat stop_gts.sh

#!/bin/bash

echo '----------------------------' >> /tmp/shutdown.log

echo `date` >> /tmp/shutdown.log

echo 'Stopping Application..' >> /tmp/shutdown.log

sudo su - gtaadm << EOF

     sapcontrol -nr 01 -function StopSystem ALL

     sapcontrol -nr 02 -function StopSystem ALL

EOF

echo `date` >> /tmp/shutdown.log

echo 'After stopping application..' >> /tmp/shutdown.log

echo 'Stopping HANA DB..' >> /tmp/shutdown.log

sudo su - gtdadm << EOF

     HDB stop

EOF

echo `date` >> /tmp/shutdown.log

echo 'After stopping HANA DB..' >> /tmp/shutdown.log

echo `date` >> /tmp/shutdown.log

While above start and stop shell scripts are bare minimal commands to stop and start services, these could be tailored to suit the requirements of the SAP landscape.

In the unit file, the timeout specific directives point to the timeout definitions when starting or stopping the service and what action to pursue if a timeout is encountered (here abort of the service start or stop is implied but this can be changed to suit the specific requirements – e.g. notify Basis administrators for the fault).

Finally, the last directive, WantedBy controls the system targets under which the service in question should be started or stopped. Since SAP services are meant to be started if the system is in a multi-user target level, this directive mentions this. Thus, for instance, if you were to start  the SLES system in a single-user mode (e.g. for any maintenance), the sapgts service would not be then started.

After the unit file is defined in /usr/lib/systemd/system, it is required to create a symbolic link for this unit file under /etc/systemd/system as shown below.

sapgts:/etc/systemd/system # ln -s /usr/lib/systemd/system/sapgts.service sapgts.service

sapgts:/etc/systemd/system # ls -ltr sapgts.service

lrwxrwxrwx 1 root root 38 Jul  7 17:49 sapgts.service -> /usr/lib/systemd/system/sapgts.service

After the symbolic link is created, all that is required is to enable the newly defined systemd service using systemctl command.

sapgts:/usr/lib/systemd/system # systemctl enable sapgts.service

After enabling the service, SAP GTS database and application services should come up whenever the system on which the service is defined is booted up in multi-user mode. Correspondingly, the services would be shutdown before the system is shutdown. You can validate this from the /tmp/startup.log and /tmp/shutdown.log files created on the system corresponding to execution of underlying commands via the respective shell scripts.

How to verify state of systemd services?

To determine if a systemd service is enabled or not, you can issue the following command:

sapgts:/usr/lib/systemd/system # systemctl is-enabled sapgts.service

enabled

If it is required to disable the systemd service, you can issue the following command:

sapgts:/usr/lib/systemd/system # systemctl disable sapgts.service

Conclusion

I hope this blog helps Basis administrators in having a clarity on how to Start/Stop SAP services by defining a systemd service on SLES 15. Would appreciate having your feedback in comments below. Should you have any further questions, feel free to include them in comments below. Optionally, you could post your Cloud queries to SAP Community soliciting responses via the wider SAP community  through this link.

If the reader is interested in having a deeper insight about systemd on SUSE Linux, it is encouraged to browse the SUSE published white paper on systemd at this link.

Happy learning!