Skip to Content
Product Information

sapconf – A way to prepare a SLES system for SAP workload – Part 1

sapconf 4 → sapconf 5

For all the people who read this post for the first time: “Nice to meet you!”
And for those who came back here due to my sapconf 5 announcement: “Welcome back!”

I wracked my brain if I should have a new series about sapconf 5 or just add some comments to my old blog posts. As you might guess, I decided for the latter.
If you read through this series you will find here and there boxes like this, labeled with “sapconf 4 -> sapconf 5”, where I explain the differences. Remember, the major change between 4 and 5 is, that we get rid of tuned.


Those who administrate systems running SAP applications on SLES may be already familiar with the configuration and tuning tool “sapconf”.
For those who don’t, now is an excellent time to do so!

A new improved version of sapconf has been released for SLES 12 SP1 onwards.
Some key improvements are:

  • one central configuration file (besides the tuned config)
  • Simplified and adjusted configuration based on current SAP notes
  • Unified sap-hana and sap-netweaver profiles to simplify deployment
  • Improved documentation

So it is worth to update or install it.

Here the minimal versions for the reworked sapconf:

4.1.12-40.47.1     (SLES 12 SP3)
4.1.12-33.15.1     (SLES 12 SP2)
4.1.12-18.24.1     (SLES 12 SP1)

In this post I will cover the installation and during the next few weeks I’ll publish further blog post about how to update and configure the new sapconf, as well as giving a few tips what you should look out for and how to achieve certain things,

To do so, I have set up a SLES 12 SP3 with the latest updates and sapconf 4.1.12-40.47.1.

NOTE: For further documentation check SAP note 1275776 and the man pages shipped with sapconf.

Let’s start!


sles12-sp3:~ # zypper install sapconf
Refreshing service 'SUSE_Linux_Enterprise_Server_12_SP3_x86_64'.
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 4 NEW packages are going to be installed:
  sapconf sysstat tuned uuidd

4 new packages to install.
Overall download size: 534.7 KiB. Already cached: 0 B. After the operation, additional 1.4 MiB will be used.
Continue? [y/n/...? shows all options] (y):
Retrieving package
(removed for brevity)
Additional rpm output:
Created symlink from /etc/systemd/system/ to /usr/lib/systemd/system/uuidd.socket.
Additional rpm output:
Updating /etc/sysconfig/sapnote-1680803...
Updating /etc/sysconfig/sapconf...
Created symlink from /etc/systemd/system/ to /usr/lib/systemd/system/sapconf.service.
Set the maximum number of OS tasks each user may run concurrently (UserTasksMax) to 'infinity'
With this setting your system is vulnerable to fork bomb attacks.
Please reboot the system for the UserTasksMax change to become effective

sapconf 4 → sapconf 5

Please ignore anything about the tuned package. It does not get pulled in by a dependency anymore!

This is quite a lot of information to digest. Let me work thru it step by step and tell you the meaning.

The following 4 NEW packages are going to be installed:
 sapconf sysstat tuned uuidd

Obviously sapconf is not the only package we have got. The packages sysstat to collect sar data, tuned for system tuning (we’ll come to it later) and uuidd which is indispensable for SAP software have been installed too.

Everyone of these packages contains units for systemd (just believe me here), so let’s see what systemd has to say about the status:

 sles12-sp3:~ # systemctl status sapconf sysstat tuned uuidd
 ● sapconf.service - sapconf
 Loaded: loaded (/usr/lib/systemd/system/sapconf.service; enabled; vendor preset: enabled)
 Active: active (exited) since Fri 2018-05-11 12:02:18 CEST; 21min ago

After the installation sapconf.service has been enabled and started.

This is important!

Sapconf is meant as a minimalistic tool to prepare your system for SAP workload. Installation implies the intend to use it, so a default configuration has been applied.

These default values are sane and should be valid for most use cases. Nevertheless you should verify that all settings are suited for your scenario.
If you feel uneasy that sapconf is changing your system directly after installation, I will show in a later article, how you can prevent this.

There is one exception when sapconf is not enabled and started by default. Because sapconf relies on tuned, a set non-sapconf profile prevents this (I will cover this in more detail in the article about sapconf configuration).
This is based under the assumption that an administrator has already configured tuned on purpose and sapconf will not interfere with this.

IMPORTANT: After installation sapconf is started and enabled unless a non-sapconf tuned profile is set already!


sapconf 4 → sapconf 5

There is no exception anymore, which could prevent sapconf 5 from being enabled on boot!
After updating to sapconf 5 tuned gets disabled and stopped.
If you enable it again tuned will work together with sapconf! If you do not configure tuned carefully you will have both tools fight each other! I have added a special chapter later, how to use both.

● sysstat.service - Write information about system start to sysstat log
 Loaded: loaded (/usr/lib/systemd/system/sysstat.service; disabled; vendor preset: disabled)
 Active: active (exited) since Fri 2018-05-11 12:02:18 CEST; 21min ago

Sysstat was started, but is disabled.
The sapconf.service will start sysstat.service automatically.

Here is the magic behind:

sles12-sp3:~ # cat /usr/lib/systemd/system/sapconf.service

As long as you use sapconf, sysstat will be started and stopped with it. When you remove the sapconf package the sysstat package will remain on the system, but the service will be inactive. You have to enable the sysstat service, if you want to use it further.
It does not do any harm to do it now if you like.
If you have objections against sysstat, I will show in a later article a way to disable it.

With tuned we see the same behavior like with sysstat. It is disabled, but started by sapconf.service.

But when we check /usr/lib/systemd/system/sapconf.service, we do not see any dependency for tuned.
To find out how it works, you have to dig deeper and check the script, that is started by the sapconf.service:

sapconf 4 → sapconf 5

Again. Please ignore this about tuned if youre using sapconf 5.

sles12-sp3:~ # cat /usr/lib/systemd/system/sapconf.service
 ExecStart=/usr/sbin/sapconf start
 sles12-sp3:~ # cat /usr/sbin/sapconf
 case "$1" in
 if ! systemctl status tuned &> /dev/null; then
 systemctl start tuned

Mystery solved.

Now, only uuidd is left:

● uuidd.service - Daemon for generating UUIDs
 Loaded: loaded (/usr/lib/systemd/system/uuidd.service; indirect; vendor preset: disabled)
 Active: inactive (dead)

Strange. Disabled and dead! But let us go back and take a closer lock to a tiny part of the rpm output above:

 Additional rpm output:
 Created symlink from /etc/systemd/system/ to /usr/lib/systemd/system/uuidd.socket.

The uuidd will be started by socket activation, so we have to check the status of the uuidd.socket and not the service:

sles12-sp3:~ # systemctl status uuidd.socket
 ● uuidd.socket - UUID daemon activation socket
 Loaded: loaded (/usr/lib/systemd/system/uuidd.socket; enabled; vendor preset: enabled)
 Active: active (listening) since Fri 2018-05-11 13:22:34 CEST; 13min ago

Ah! Enabled and active. How it should be.

Another glance at the service file of sapconf connects the dots:

sles12-sp3:~ # cat /usr/lib/systemd/system/sapconf.service

There are a few lines left:

Updating /etc/sysconfig/sapnote-1680803...
Updating /etc/sysconfig/sapconf...

Some configuration files have been updated.
I skip these for now, because I tell more about the configuration of sapconf in the next article.

Created symlink from /etc/systemd/system/ to /usr/lib/systemd/system/sapconf.service.

Well, here we see that the sapconf service is enabled for the multi-user target. We have found out that already.

Set the maximum number of OS tasks each user may run concurrently (UserTasksMax) to 'infinity'
With this setting your system is vulnerable to fork bomb attacks.
Please reboot the system for the UserTasksMax change to become effective

A reboot is required!

Here a systemd limit (UserTasksMax) is set to infinity, because the system default is to low for most SAP workloads.

Those who have more knowledge about systemd might argue, that a reboot is not required. Users should log off and log on again, programs have to be restarted, and so on and so on. This might be true, but in real life the chance that something is overseen even by a skilled administrator is high. A reboot is much easier and makes sure that the changes are in effect.
Even if sapconf tries to avoid reboots, sometimes it is unavoidable.

IMPORTANT: Please always check the output of the rpm to see, if additional steps are required after installation.

Sapconf is installed and working with its defaults. I have tried to summarize the dependencies in this picture:


sapconf 4 → sapconf 5

I have updated the graphic for sapconf 5:


Dependencies of sapconf 5


That’s it for today. The next article will cover the configuration.


next article: sapconf – A way to prepare a SLES system for SAP workload – Part 2


You must be Logged on to comment or reply to a post.
  • Hello Soren,

    Thank you for informative blog. It will be great if you can answer below queries.

    1. To prepare SLES for SAP environments we need to install either sapconf or saptune. Is this right understanding?


    2. We are planning for SLES15 SP1. In this version, shall we only go for sapconf which comes with 1 profile sapconf for all both- Application server and HANA DB as well?


    3. Note 2684254 – SAP HANA DB: Recommended OS settings for SLES 15 / SLES for SAP Applications 15 has below line for many parameters

    Configure saptune with solution HANA respectively sapconf with sap-hana profile according to note 1275776.

    This is not clear as it talks about both saptune and sapconf. Can we simply use sapconf (SLES 15 SP1) which comes with just one profile- sapconf? Will it cover these HANA DB related parameters?




    • Hi Vinod,


      I haven't got a notification that a new comment was added.

      To your questions:

      1. Yes, Either sapconf or saptune.
      2. Correct. Sapconf does only the minimum whic is valid for HANA and App Server. If you want to have more complete and specific tuning, saptune is the better choice.
      3. The SAP Note needs a bit polishing. I will talk to the author. It tries to cover both tools.
        You can use sapconf. If I'm not mistaken all recommendations are part of sapconf, but you have to enable the CPU-Tuning explicitly!