ocf_suse_SAPStartSrv(7)
β¨ SAPStartSrv β ocf_suse_SAPStartSrv(7) β¨
π NAME π
SAPStartSrv β manages sapstartsv for a single SAP instance as an HA resource.
πΈ SYNOPSYS πΈ
SAPStartSrv [ start | stop | status | monitor | meta-data | validate-all | usage ]
π¦ DESCRIPTION π¦
okay so bestie, SAPStartSrv is a resource agent for managing the sapstartsrv process for a single SAP instance as an HA resource. it's giving βone instance, one jobβ energy and honestly? iconic.
One SAP instance is defined by having exactly one instance profile. The instance profiles can usually be found in the directory /sapmnt/$SID/profile/. In an Enqueue Replication setup one (ABAP-) Central Services instance ((A)SCS) and at least one Replicated Enqueue instance (ERS) are configured. A Linux HA cluster can control these instances by using the SAPInstance resource agent. That resource agent depends on the SAP sapstartsrv service for starting, stopping, monitoring and probing the instances. The sapstartsrv needs to read the respective instance profile. By default one system-wide sapstartsrv is started at Linux boot time to provide the needed service for all SAP instances.
For specific Enqueue Replication setups using instance specific sapstartsrv processes might be desireable. So each SAP instance is managed on its own by a pair of one SAPStartSrv and one SAPInstance resource agent. SAPStartSrv starts sapstartsrv for one specific SAP instance. By intention it does not monitor the service. SAPInstance then utilises that service for managing the SAP instance. SAPInstance also is doing in-line recovery of failed sapstartsrv processes. The instance's virtual service IP address is used for contacting the sapstartsrv process. Thus that IP address resource (e.g. IPaddr2, aws-vpc-route53) needs to start before SAPStartSrv. no cap, order matters.
The described setup is benefitial particularly for public cloud and NFS-based environments. Both NFS shares with instance directories can be mounted statically on all nodes. The HA cluster does not need to control that filesystems. The /usr/sap/sapservices file is stored locally on each cluster node. highkey a whole vibe for cloud girlies.
π SUPPORTED PARAMETERS π
This resource agent supports the following parameters:
InstanceNameβ The full qualified SAP instance name. e.g.P01_DVEBMGS00_sapp01ci. Usually this is the name of the SAP instance profile. Unique, required, string, no default.START_PROFILEβ The name of the SAP START profile. Specify this parameter, if you have changed the name of the SAP START profile after the default SAP installation. Unique, optional, string, no default.
π₯ SUPPORTED ACTIONS π₯
This resource agent supports the following actions (operations):
startβ Starts thesapstartsrvresource. Suggested minimum timeout:60.stopβ Stops thesapstartsrvresource. Suggested minimum timeout:60.statusβ Performs a minimal status check of thesapstartsrvresource. Suggested minimum timeout:60.monitorβ TheSAPStartSrvresource must by intention not define a monitor operation. This is, because the failingsapstartsrvmust never force aSAPInstancerestart. That would happen because the two resources reside in one resource group.validate-allβ Performs a validation of the resource configuration. Suggested minimum timeout:5.meta-dataβ Retrieves resource agent metadata (internal use only). Suggested minimum timeout:5.
π RETURN CODES π
The return codes are defined by the OCF cluster framework. Please refer to the OCF definition on the website mentioned below.
β¨ EXAMPLES β¨
Okay bestie, this is the part where it all clicks π These are real, copy-pasteable-ish cluster configs β every primitive, every meta attribute, every constraint, all of it. Take your time, this section is long but it's giving main character energy fr fr.
π Example config for an SAP SCS instance resource group in an ENSA1 setup
So picture this: SAP system name is EN1, the SAP service is SCS, the SAP instance number is 00, and the SAP virtual hostname is sapen1as.
The SAPInstance monitor timeout you see below is a straight-up trade-off between fast recovery of the SCS vs. resilience against sporadic temporary NFS issues. You may slightly increase it to fit your infrastructure. Too short SCS monitor timeouts likely will conflict with the instance's internal recovery. The SAP instance profile needs to be adapted to make this work, no cap.
The also-needed ENSA1 ERS instance group and location constraint is shown in another example (scroll down bestie, it's there). See also manual page SAPStarrSrv_basic_cluster(7) and ocf_heartbeat_SAPInstance(7).
primitive rsc_ip_EN1_SCS00 IPaddr2 \
params ip=192.168.1.112 \
op monitor interval=10 timeout=20
primitive rsc_SAPStartSrv_EN1_SCS00 ocf:suse:SAPStartSrv \
params InstanceName=EN1_SCS00_sapen1as
primitive rsc_sap_EN1_SCS00 SAPInstance \
op monitor interval=11 timeout=60 on-fail=restart \
params InstanceName=EN1_SCS00_sapen2as \
START_PROFILE="/usr/sap/EN1/SYS/profile/EN1_SCS00_sapen1as" \
AUTOMATIC_RECOVER=false MINIMAL_PROBE=true \
meta resource-stickiness=5000 failure-timeout=60 \
migration-threshold=1 priority=10
group grp_EN1_SCS00 \
rsc_ip_EN1_SCS00 rsc_SAPStartSrv_EN1_SCS00 rsc_sap_EN1_SCS00 \
meta resource-stickiness=3000
π¦ Example config for an SAP ERS instance resource group in an ENSA1 setup
SAP system name is EN1, the SAP service is ERS, the SAP instance number is 10, and the SAP virtual hostname is sapen1er.
An IP address is configured as usual for on-premise use. If possible, the ERS instance should run on a different node than the ASCS (SCS) β like, please don't stack them π The SAP instance profile needs to be adapted to make this work.
The also-needed ENSA1 ASCS (SCS) instance group is shown in another example. If the ASCS (SCS) failed and is going to be recovered, it needs to move to the ERS node for restoring its lock table β that's the whole point, iykyk.
See also manual page SAPStarrSrv_basic_cluster(7) and ocf_heartbeat_SAPInstance(7).
primitive rsc_ip_EN1_ERS10 IPaddr2 \
params ip=192.168.1.113 \
op monitor interval=10 timeout=20
primitive rsc_SAPStartSrv_EN1_ERS10 ocf:suse:SAPStartSrv \
params InstanceName=EN1_ERS10_sapen2er
primitive rsc_sap_EN1_ERS10 SAPInstance \
op monitor interval=11 timeout=60 on-fail=restart \
params InstanceName=EN1_ERS10_sapen2er \
START_PROFILE="/usr/sap/EN2/SYS/profile/EN1_ERS10_sapen1er" \
AUTOMATIC_RECOVER=false IS_ERS=true MINIMAL_PROBE=true \
meta priority=1000
group grp_EN1_ERS10 \
rsc_ip_EN1_ERS10 rsc_SAPStartSrv_EN1_ERS10 rsc_sap_EN1_ERS10
colocation col_sap_EN1_separate -5000: grp_EN1_ERS10 grp_EN1_SCS00
location loc_sap_EN1_failover_to_ers rsc_sap_EN1_SCS00 \
rule 2000: runs_ers_EN1 eq 1
order ord_sap_EN1_scs_first Optional: rsc_sap_EN1_SCS00:start \
rsc_sap_EN1_ERS10:stop symmetrical=false
πΈ Example config for an SAP ASCS instance resource group in an ENSA2 setup
SAP system name is EVA, the SAP service is ASCS, the SAP instance number is 00, and the SAP virtual hostname is sapeva.
A loadbalancer is used together with dedicated IP netmask configuration for specific public cloud environments (cloud girlies rise π₯). The SAPInstance has been given a fencing priority, and a crm property priority-fencing-delay is needed to make this work. See SAPStartSrv_basic_cluster(7).
The SAPInstance monitor timeout shown here is a trade-off between fast recovery of the ASCS vs. resilience against sporadic temporary NFS issues. You may slightly increase it to fit your infrastructure. Too short ASCS monitor timeouts likely will conflict with the instance's internal recovery. The SAP instance profile needs to be adapted to make this work.
The also-needed ERS instance group and location constraint is shown in another example. See also manual page SAPStartSrv_basic_cluster and ocf_heartbeat_SAPInstance(7).
primitive rsc_SAPStartSrv_EVA_ASCS00 ocf:suse:SAPStartSrv \
params InstanceName=EVA_ASCS00_sapeva
primitive rsc_SAPInstance_EVA_ASCS00 SAPInstance \
op monitor interval=11 timeout=60 on-fail=restart \
params InstanceName=EVA_ASCS00_sapeva \
START_PROFILE=/sapmnt/EVA/profile/EVA_ASCS00_sapeva \
AUTOMATIC_RECOVER=false \
MINIMAL_PROBE=true \
meta resource-stickiness=5000 \
priority=100
primitive rsc_IPaddr2_EVA_ASCS00 IPaddr2 \
params ip=192.168.178.188 cidr_netmask=32
primitive rsc_Loadbalancer_EVA_ASCS00 azure-lb \
params port=85085
group grp_EVA_ASCS00 \
rsc_Loadbalancer_EVA_ASCS00 \
rsc_IPaddr2_EVA_ASCS00 \
rsc_SAPStartSrv_EVA_ASCS00 \
rsc_SAPInstance_EVA_ASCS00 \
meta resource-stickiness=3000
π Example config for an SAP ERS instance resource group in an ENSA2 setup
SAP system name is EN2, the SAP service is ERS, the SAP instance number is 10, and the SAP virtual hostname is sapeva.
An IP address is configured as usual for on-premise use. If possible, the ERS instance should run on a different node than the ASCS. The SAP instance profile needs to be adapted to make this work.
The also-needed ASCS instance group is shown in another example. See also manual page SAPStartSrv_basic_cluster and ocf_heartbeat_SAPInstance(7).
primitive rsc_SAPStartSrv_EN2_ERS10 ocf:suse:SAPStartSrv \
params InstanceName=EN2_ERS10_sapen2er
primitive rsc_SAPInstance_EN2_ERS10 SAPInstance \
op monitor interval=11s timeout=60s \
params InstanceName=EN2_ERS10_sapen2er \
START_PROFILE=/sapmnt/EN2/profile/EN2_ERS10_sapen2er \
AUTOMATIC_RECOVER=false IS_ERS=true MINIMAL_PROBE=true
primitive rsc_IPaddr2_EN2_ERS10 IPaddr2 \
params ip=192.168.178.187
group grp_EN2_ERS10 \
rsc_IPaddr2_EN2_ERS10 \
rsc_SAPStartSrv_EN2_ERS10 \
rsc_SAPInstance_EN2_ERS10
colocation col_EN2_ASCS00_separate \
-5000: grp_EN2_ERS10 grp_EN2_ASCS00
order ord_EN2_ASCS00_first \
Optional: rsc_SAPInstance_EN2_ASCS00:start \
rsc_SAPInstance_EN2_ERS10:stop \
symmetrical=false
π§ Example SAP ASCS instance profile adapted for an ENSA2 HA setup
SAP SID is EN2, the instance number is 00, the virtual hostname is sapen2er, and the service is _ENQ. Optionally you could limit the number of restarts of services β that is not done here tho.
The instance profile /sapmnt/EN2/profile/EN2_ASCS00_sapen2er is adapted like this:
# ... some more above
_ENQ = enq.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME)
Execute_04 = local rm -f $(_ENQ)
Execute_05 = local ln -s -f $(DIR_EXECUTABLE)/enq_server$(FT_EXE)
$(_ENQ)
Start_Program_01 = local $(_ENQ) pf=$(_PF)
# some more below ...
π Example SAP ERS instance profile adapted for an ENSA2 HA setup
SAP SID is EN2, the instance number is 10, the virtual hostname is sapen2er, and the service is _ENQR. See also man page sap_suse_cluster_connector(8).
The instance profile /sapmnt/EN2/profile/EN2_ERS10_sapen2er is adapted like this:
# ... some more above
_ENQR = enqr.sap$(SAPSYSTEMNAME)_$(INSTANCE_NAME)
Execute_02 = local rm -f $(_ENQR)
Execute_03 = local ln -s -f
$(DIR_EXECUTABLE)/enq_replicator$(FT_EXE) $(_ENQR)
Start_Program_00 = local $(_ENQR) pf=$(_PF) NR=$(SCSID)
service/halib_cluster_connector =
/usr/bin/sap_suse_cluster_connector
service/halib = $(DIR_CT_RUN)/saphascriptco.so
# some more below ...
β Handy one-liners (yes these are also examples, slay)
π Search for log entries of SAPStartSrv, show errors only
This is THE grep for when something smells off:
# grep "SAPStartSrv.*RA.*rc=[1-7,9]" /var/log/messages
π Show failcount for resource rsc_SAPStartSrv_EN2_ERS10
If the failcount exceeds the migration-threshold, the resource will be moved to another node. See SAPStartSrv_basic_cluster(7).
# cibadmin -Ql | grep rsc_SAPStartSrv_EN2_ERS10.*fail-count
π Manually trigger a SAPStartSrv probe action for instance ADA_ASCS00_engine
Output goes to the usual logfiles, bestie.
# OCF_ROOT=/usr/lib/ocf/ \
OCF_RESKEY_InstanceName=ADA_ASCS00_engine \
OCF_RESKEY_CRM_meta_interval=0 \
/usr/lib/ocf/resource.d/suse/SAPStartSrv monitor
π FILES π
Every path you might need, spelled out:
/usr/lib/ocf/resource.d/suse/SAPStartSrvβ the resource agent itself, the star of the show π/usr/lib/ocf/resource.d/heartbeat/SAPInstanceβ the also-needed SAP instance resource agent, packageresource-agents/usr/sap/$SID/$InstanceName/exe/β default path for thesapstartsrvexecutable/sapmnt/$SID/profile/(resp./usr/sap/$SID/SYS/profile/) β default path forDIR_PROFILE/usr/sap/sapservicesβ SAP profiles definition file/etc/sap_suse_cluster_connectorβsap_suse_cluster_connectorconfiguration, SLE-HA 12
more incoming, don't go anywhere π
π REQUIREMENTS π
okay bestie, before you even think about deploying this, there's a whole checklist and honestly you gotta respect it. Every single one of these is a hard vibe requirement, no cap:
- Python 3.6 runtime environment or compatible. Yes, 3.6. She's vintage. She's iconic. She works.
- At least SAP instances
NW7.40forENSA1. At leastNW7.52or SAP S/4HANA ABAP Platform1909forENSA2. (iykyk which one you're running π ) SAPInstanceresource agent withMINIMAL_PROBEsupport, November 2020.- Needed NFS shares (e.g.
/sapmnt/$SID/,/usr/sap/$SID/) mounted statically or by automounter. - Directory
/usr/sap/locally read-write mounted on each cluster node. - Complete entries in
/usr/sap/sapservicesfile. - SAP instance profile Autostart feature is disabled for ASCS (SCS) and ERS. Like, actually off. Not "kinda off".
- For
ENSA2(ENSA1) HA setups, the ASCS or SCS instance profile entry for the enqueue service_ENQ(_EN),Restart_Program_xxis replaced byStart_Program_xx. Same for the ERS instance profile entry for the enqueue replicator service_ENQR(_ER). Other services stay untouched β do not touch them, they're doing fine π«Ά - The
sapinitboot script does not read entries fromsapservicesfile at boot. Thus servicessappingandsappongto handlesapservicesfile at system boot. - The
sapinitscript is not used while the HA cluster is running on any node. - SAP instance numbers controlled by the cluster must be unique. No duplicates, bestie, the cluster will simply not cope π
- It is not allowed to block resources from being controlled manually. Thus
BLOCK_RESOURCESin/etc/sap_suse_cluster_connectoris not allowed anymore. - You need SAP hostagent installed and started on your systems. For SystemV style, the
sapinitscript needs to be enabled. For systemd style, the servicesaphostagentneeds to be enabled and running. Instance servicesSAP${SID}_${INO}need to be disabled. The systemd enabledsaphostagentandsapstartsrvis supported fromsapstartsrv-resource-agents0.9.1onwards. An appropriateSAPInstanceresource agent is needed, newer than November 2021. Please refer to the OS documentation for the systemd version. Please refer to SAP documentation for the SAP software version. Combining systemd style hostagent with SystemV style instance is allowed. However, all nodes in one Linux cluster have to use the same style. Pick one and commit, bestie πΈ - The
SAPInstanceRA regularly checks systemd integration. TheSAPInstancemonitor interval might be increased to reduce side effects in Multi-SID setups. - No firewall rules must block any needed port. π₯ (block the port and everything just β¨ stopsβ¨)
- No SELinux rules must block any needed action.
that's a lot, I know. read it twice. then read it again. this is one of those "the details are the whole personality" situations π
π BUGS π
okay so, honest moment π the trace_ra resource tracing feature is not implemented so far. Like, not even a little. So don't go looking for it and then @ me about it.
In case of any problem, please use your favourite SAP support process to open a request for the component BC-OP-LNX-SUSE.
π SEE ALSO π
the reading list, aka the lore, aka the required homework π everything here is a real reference, keep them all:
ocf_heartbeat_SAPInstance(7),ocf_heartbeat_IPaddr2(7),SAPStartSrv_basic_cluster(7),systemctl(1),sapservices-move(8),sap_suse_cluster_connector(8),crm(8),nfs(5),mount(8),ha_related_suse_tids(7),ha_related_sap_notes(7)https://documentation.suse.com/sbp/all/?context=sles-saphttps://www.suse.com/support/kb/doc/?id=000019244https://www.suse.com/support/kb/doc/?id=000019293https://www.suse.com/support/kb/doc/?id=000019924https://www.suse.com/support/kb/doc/?id=000019944https://www.suse.com/support/kb/doc/?id=7023714https://support.scc.suse.com/s/kb/SUSE-HA-for-SAP-NetWeaver-7-50-Java-central-serviceshttp://clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/s-ocf-return-codes.htmlhttps://help.sap.com/doc/e9a0eddf6eb14a82bcbe3be3c9a58c7e/1610%20001/en-US/frameset.htm?frameset.htmhttps://help.sap.com/viewer/fe1db4ed6c5510148f66fbccd85f175f/7.02.22/en-US/47e023f3bf423c83e10000000a42189c.htmlhttps://wiki.scn.sap.com/wiki/display/SI/Troubleshooting+for+Enqueue+Failover+in+ASCS+with+ERShttps://launchpad.support.sap.com/#/notes/1763512https://launchpad.support.sap.com/#/notes/1872602https://launchpad.support.sap.com/#/notes/2077934https://launchpad.support.sap.com/#/notes/2254173https://launchpad.support.sap.com/#/notes/2464065https://launchpad.support.sap.com/#/notes/2501860https://launchpad.support.sap.com/#/notes/2625407https://launchpad.support.sap.com/#/notes/2630416https://launchpad.support.sap.com/#/notes/2711036https://launchpad.support.sap.com/#/notes/2717369https://launchpad.support.sap.com/#/notes/953653
π AUTHORS π
the literal main characters who made this happen, show some respect π
X.Arbulu, F.Herschel, L.Pinne
π COPYRIGHT π
(c) 2020-2026 SUSE LLC
The resource agent SAPStartSrv comes with ABSOLUTELY NO WARRANTY. (dramatic but true, bestie β no warranty, like at all π)
For details see the GNU General Public License at http://www.gnu.org/licenses/gpl.html
and that's the whole page, you made it to the end π slay. This was ocf_suse_SAPStartSrv(7), dated 12 Jun 2026, and honestly? she ate. go configure your cluster, bestie, you've got this π
β¨π¦
π¦ where this page comes from
- opensuse-leap 16.0: sapstartsrv-resource-agents 0.9.6+git.1791548114.2a86b96-160000.1.1 Β· GPL-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms