This is the fifth and last article about sapconf and it will tie up lose ends.
NOTE: For further documentation check SAP note 1275776 and the man pages shipped with sapconf.
sapconf 4 → sapconf 5
The following list is quite long, so If decided to make two sections. One for sapconf 4 and one for sapconf 5.
Summary of important things (sapconf 4)
If you install the reworked sapconf version for the first time:
- After installation, sapconf is enabled and started immediately with a default configuration, if no other tuned profile was set.
- Leave the profile 'sap-netweaver' (or switch to 'sap-hana' if you really want) even if you run HANA, BOBJ or ASE.
- Verify both main configuration files /etc/sysconfig/sapconf and /usr/lib/tuned//tuned.conf.
- Verify that parameters handled by sapconf are not configured elsewhere (e.g. boot parameter, sysctl.conf, etc.).
If you update to the reworked sapconf version:
- After the update sapconf will immediately apply the shipped default configuration, if sapconf is running.
- Manually transfer any configuration from your old configuration (/etc/sysconfig/sapconf.rpmsave) to the new one (/etc/sysconfig/sapconf). Do not copy any files!.
- If you have a sapconf profile in /etc/tuned/, copy the new profile from /usr/lib/tuned/ and alter it.
- Move away from the profiles 'sap-ase' and 'sap-bobj'..
- Verify both main configuration files /etc/sysconfig/sapconf and /usr/lib/tuned//tuned.conf, if they fit your needs.
- Verify that parameters handled by sapconf are not configured elsewhere (e.g. boot parameter, sysctl.conf, etc.).
If you remove (the re-worked) sapconf:
- Enable sysstat.service if you want to use it further.
- Check if tuned.service is enabled! After removal the profile is empty and tuned will choose its default profile. The result might not be what you want.
- The uuidd, nofile user limits and DefaultTasksMax are not going away. No worries.
Always a good idea:
- Read the rpm output after an installation or update!
- Read the man pages carefully!
- Check the rpm changelog to find out, what has been changed!
- Check SAP note 1275776 for changes.
Summary of important things (sapconf 5)
If you install the sapconf 5 for the first time:
- After installation, sapconf is enabled and started immediately with a default configuration always.
- Leave the profile netweaver (or switch to hana if you really want) even if you run HANA, BOBJ or ASE.
- Verify the main configuration file /etc/sysconfig/sapconf.
- Verify that parameters handled by sapconf are not configured elsewhere (e.g. boot parameter, sysctl.conf, etc.).
If you update from sapconf 4 to sapconf 5:
- If you had a customized tuned profile with additional parameters added, create your own tuned profile for them (and only them) and enable tuned.service.
- Manually transfer any configuration from your old configuration (/etc/sysconfig/sapconf.rpmsave) to the new one (/etc/sysconfig/sapconf). Do not copy any files!
- Check your workflows, scripts, etc. for tuned-related commands and replace them.
- Move away from the profiles sap-ase and sap-bobj.
- Verify the main configuration file /etc/sysconfig/sapconf if it fits your needs.
- Verify that parameters handled by sapconf are not configured elsewhere (e.g. boot parameter, sysctl.conf, etc.).
If you remove sapconf 5:
- Enable sysstat.service if you want to use it further.
- The uuidd, nofile user limits and DefaultTasksMax are not going away. No worries.
Always a good idea:
- Read the rpm output after an installation or update!
- Read the man pages carefully!
- Check the rpm changelog to find out, what has been changed!
- Check SAP note 1275776 for changes.
How to prevent autostart of sapconf after installation?
sapconf 4 → sapconf 5
This still applies to sapconf 5.
I promised earlier, that I would show a way to prevent the automatic start of sapconf after installation.
Here it is.
Before you install sapconf, you have to mask the not yet existing
sapconf.service.
I have brought my system back to state when sapconf wasn't installed.
...
(reset vm)
...
sles12-sp3:~ # rpm -q sapconf sysstat tuned uuidd
package sapconf is not installed
package sysstat is not installed
package tuned is not installed
package uuidd is not installed
Now I mask the sapconf service:
sles12-sp3:~ # systemctl mask sapconf.service
Created symlink from /etc/systemd/system/sapconf.service to /dev/null.
And install sapconf:
sles12sp3-sapconftest:~ # zypper install sapconf
...
Failed to execute operation: Unit file is masked
...
Output of sapconf-4.1.12-40.47.1.noarch.rpm %posttrans script:
Failed to start sapconf.service: Unit sapconf.service is masked.
The end of the output differs from that what we have seen before. The masked unit has been detected and sapconf was neither enabled nor started.
Let's verify this:
sles12-sp3:~ # systemctl status sapconf
● sapconf.service
Loaded: masked (/dev/null; masked)
Active: inactive (dead)
Has this an impact on our other services?
sles12-sp3:~ # systemctl status tuned.service sysstat.service uuidd.socket
● tuned.service - Dynamic System Tuning Daemon
Loaded: loaded (/usr/lib/systemd/system/tuned.service; disabled; vendor preset: disabled)
Active: inactive (dead)
Tuned is disabled and inactive. Since sapconf starts it, this was expected.
● sysstat.service - Write information about system start to sysstat log
Loaded: loaded (/usr/lib/systemd/system/sysstat.service; disabled; vendor preset: disabled)
Active: inactive (dead)
The same with sysstat.
● uuidd.socket - UUID daemon activation socket
Loaded: loaded (/usr/lib/systemd/system/uuidd.socket; enabled; vendor preset: enabled)
Active: inactive (dead)
Listen: /run/uuidd/request (Stream)
This looks not that good. The socket is enabled, but inactive! If we do nothing the
uuidd.socket will be available after the next reboot earliest.
But before you complain, let us remember why we masked the sapconf service in the first place. The goal was to prevent an autostart after installation to have a chance to alter the configuration to our needs!
This worked! And now we configure sapconf....
...
Done. What next?
We unmask, enable and start the sapconf service:
sles12-sp3:~ # systemctl unmask sapconf.service
Removed symlink /etc/systemd/system/sapconf.service.
sles12-sp3:~ # systemctl enable sapconf.service
Created symlink from /etc/systemd/system/multi-user.target.wants/sapconf.service to /usr/lib/systemd/system/sapconf.service.
sles12-sp3:~ # systemctl start sapconf.service
If you check again the status of
tuned,
sysstat and
uuidd, you will see that everything is fine now.
How to disable sysstat?
sapconf 4 → sapconf 5
This still applies to sapconf 5.
You do not want sar data collected for some reason. Its your prerogative. But how to do it?
Deinstallation is not an option!
You would break the rpm dependencies and the package would be reinstalled at the next update. Yes, you could lock the package, but no need for that. Besides you might want to have to the sysstat tools installed for a manual analysis of your system.
To prevent the start of
sysstat.service by sapconf, just mask the service. If you know this in advance, you can do it before the installation of sapconf. If you want to do it later, you *must* stop the sysstat service first!
sles12-sp3:~ # systemctl stop sysstat.service
sles12-sp3:~ # systemctl mask sysstat.service
Created symlink from /etc/systemd/system/sysstat.service to /dev/null.
Why that? The sysstat service creates a link for cron on start and removes it again at stop:
sles12-sp3:~ # cat /usr/lib/systemd/system/sysstat.service
...
ExecStart=/bin/ln -fs /etc/sysstat/sysstat.cron /etc/cron.d/sysstat
ExecStop=/bin/rm -f /etc/cron.d/sysstat
...
If you mask the service
after sysstat has been started, the link will never removed and the sar data are still collected regulary - exactly that, what you do not want!
Is sapconf deprecated?
sapconf 4 → sapconf 5
You should not see any messages like this anymore.
If you browse thru the log files - and as a careful admin you do of cause - you might stumble across these lines:
sles12-sp3:~ # cat /var/log/messages
...
2018-05-15T15:03:09.422940+02:00 sles12-sp3 sapconf[2183]: Warning: sapconf is deprecated. Please use system tuning daemon (tuned) instead.
...
Don't worry! This message was just missed during rework and is an obsolete statement. Sapconf will be there for you in SLES 12 and SLES 15.
With one of the next updates it will be fixed. So please update regularly as you always do.
😉
What about sysctl?
sapconf 4 → sapconf 5
This still applies to sapconf 5.
Lately I have been asked about how sapconf plays together with sysctl.
How does sysctl works?
Old stagers know from their experience with SLES 11, that you have to put your configuration into
/etc/sysctl.conf and apply it with
sysctl -p or let the boot script
/etc/init.d/boot.sysctl do the job.
On SLES 12 the configuration should be put into
/etc/sysctl.d/ (you find a compatibility link for
/etc/sysctl.conf:
99-sysctl.conf -> /etc/sysctl.conf/ there).
The command
sysctl works as usual, but the SysV init script has been replaced with the systemd-sysctl service (For more details, please read the man pages of
systemd-sysctl.service and
sysctl.d.).
The unit file of sapconf lists the dependencies:
sles12-sp3:~ # cat /usr/lib/systemd/system/sapconf.service
[Unit]
Description=sapconf
After=syslog.target systemd-sysctl.service network.target
...
systemd-sysctl.service comes first,
sapconf.service later, so sapconf will win and overwrite the values of
/etc/sysctl.d/*.
If an admin or a tool executes
sysctl -p later, than the values are overwritten. Because tuned does not verify the profile regularly, the values will stay until tuned is ordered to change or re-apply a profile.
You see, that confusion is almost guaranteed if you configure the parameters sapconf takes care of for sysctl as well. Avoid it!
That's it folks!
I hope I covered the most important aspects of sapconf. If you feel that something s missing, let me know. I will update the series - especially this post - from time to time, if I will be asked something again and again.
previous article:
sapconf – A way to prepare a SLES system for SAP workload – Part 4
