Technical Articles
Using systemd to Start/Stop SAP services on SUSE Linux
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!
Thanks for the post. I have adapted the scripts for the 7.52SP04 demo I have on OpenSuse 15.2 but I got a couple of issues:
For this last and bigger issue, Suse has a support document and I ended up modifying /etc/pam.d/su* instead of just /etc/pam.d/su
Now the shutdown lasts longer and the journal log shows a normal shutdown.
Thanks for the update and tips Andrea.
Someone planning to use the scripting approach should definitely find it useful.
Thanks!
BR, Rakesh
SAP official development on this is now available for up to date kernels. Check more details in note 3139184- linux: systesmd integration for sapstartsrv and SAP Host Agent
Yes, but that note needs to be improved upon for ease of understanding and use. Surely a native way to control SAP services via systemd is welcome but in its current form, the note is not something that can be easily understood and adopted, in my opinion.
Please refer to 3115048 - sapstartsrv native Linux systemd