Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Cause:
The systemd-sysctl is run multiple times from mutliple places so the ordering specified in Tuned service file didn't work and tuned was run after systemd-sysctl service.
Consequence:
Sysctl parameters could be overwritten by systemd.
Fix:
Workaround was added to Tuned service file causing that the Tuned is run after the network script which is the place from which the last run of systemd-sysctl is initiated.
Result:
Tuned is run after systemd-sysctl.
Created attachment 988286[details]
My custom oracle tuned profile
Description of problem:
I've created a custom tuned profile that sets kernel.shmmax and kernel.shmall among other parameters. When I start the tuned service, set the tuned profile using the command: tuned-adm profile <profile-name>, all parameters are set as intended. However, when I reboot the system, even though my custom tuned profile is set, all parameters within my custom tuned profile are set except for the kernel.shmmax and kernel.shmall values. I can reproduce this issue 100% of the time. If I reload the tuned profile using the command: tuned-adm profile <profile-name> the custom profile then properly loads all my kernel parameters including the kernel.shmmax and kernel.shmall
Version-Release number of selected component (if applicable):
tuned-2.3.0-11.el7
How reproducible:
100%
Steps to Reproduce:
1.Copy custom tuned profile i.e. mine is named oracle, within the /usr/lib/tuned directory
2. systemctl start tuned.service
3. systemctl enable tuned.service
4. tuned-adm profile oracle
5. Verify tuned custom oracle profile is active:
# tuned-adm active
Current active profile: oracle
6. Verify parameters are set via checking using sysctl -a command
# sysctl -a | grep kernel.shmmax
kernel.shmmax = 4398046511104
7. Verify that parameter goes back to original setting when tuned service is stopped.
# systemctl stop tuned.service
8. Verify parameter kernel.shmmax
# sysctl -a | grep kernel.shmmax
kernel.shmmax = 4294967295
9. Restart the tuned service
# systemctl restart tuned.service
10. Reboot the system
11. Once system is available, check active profile
# tuned-adm active
Current active profile: oracle
12. Verify kernel.shmmax value:
# sysctl -a | grep kernel.shmmax
kernel.shmmax = 4294967295
Due to the oracle profile being the active profile, kernel.shmmax should of been set to 4398046511104 not 4294967295. The same issue happens with kernel.shmall where the value set in my profile is not used and default system value is used instead. This issue only happens during a reboot and I do not see it happen during a stop and start of the tuned service. I'm attaching the files script.sh and tuned.conf that reside within the oracle profile directory.
Comment 2Jaroslav Škarvada
2015-06-25 16:19:25 UTC
It's overwritten by systemd-sysctl service when applying /lib/sysctl.d/00-system.conf. This file is provided by 'initscripts' package. It seems this functionality has been dropped in initscripts-9.49.25-1, from the changelog:
> sysctl.conf: drop SHMALL and SHMMAX, they have sane default values in kernel
But I can change the tuned.service priority to run after systemd-sysctl to avoid similar problems that could appear later.
Comment 3Jaroslav Škarvada
2015-06-25 16:51:18 UTC
(In reply to Jaroslav Škarvada from comment #2)
> But I can change the tuned.service priority to run after systemd-sysctl to
> avoid similar problems that could appear later.
Unfortunately it seems there is systemd bug 1235768 preventing doing this.
Comment 4Jaroslav Škarvada
2015-06-26 10:00:39 UTC
Comment 5Jaroslav Škarvada
2015-06-26 15:40:07 UTC
(In reply to Jaroslav Škarvada from comment #4)
> (In reply to Jaroslav Škarvada from comment #3)
> > (In reply to Jaroslav Škarvada from comment #2)
> > > But I can change the tuned.service priority to run after systemd-sysctl to
> > > avoid similar problems that could appear later.
> >
> > Unfortunately it seems there is systemd bug 1235768 preventing doing this.
>
> I pushed tuned fix upstream, commit:
> https://git.fedorahosted.org/cgit/tuned.git/commit/
> ?id=aa0644f06f1e34b18bf5231fcd61bb53924a9e1b
>
> But it needs to be fixed in systemd for the tuned fix to work.
Systemd/initscripts bug is closed can't fix, so I introduced workaround in the following upstream tuned commit:
https://git.fedorahosted.org/cgit/tuned.git/commit/?id=dd9ee3ef5d207f766d01688184ff8b717483a56f
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2015-2375.html
Created attachment 988286 [details] My custom oracle tuned profile Description of problem: I've created a custom tuned profile that sets kernel.shmmax and kernel.shmall among other parameters. When I start the tuned service, set the tuned profile using the command: tuned-adm profile <profile-name>, all parameters are set as intended. However, when I reboot the system, even though my custom tuned profile is set, all parameters within my custom tuned profile are set except for the kernel.shmmax and kernel.shmall values. I can reproduce this issue 100% of the time. If I reload the tuned profile using the command: tuned-adm profile <profile-name> the custom profile then properly loads all my kernel parameters including the kernel.shmmax and kernel.shmall Version-Release number of selected component (if applicable): tuned-2.3.0-11.el7 How reproducible: 100% Steps to Reproduce: 1.Copy custom tuned profile i.e. mine is named oracle, within the /usr/lib/tuned directory 2. systemctl start tuned.service 3. systemctl enable tuned.service 4. tuned-adm profile oracle 5. Verify tuned custom oracle profile is active: # tuned-adm active Current active profile: oracle 6. Verify parameters are set via checking using sysctl -a command # sysctl -a | grep kernel.shmmax kernel.shmmax = 4398046511104 7. Verify that parameter goes back to original setting when tuned service is stopped. # systemctl stop tuned.service 8. Verify parameter kernel.shmmax # sysctl -a | grep kernel.shmmax kernel.shmmax = 4294967295 9. Restart the tuned service # systemctl restart tuned.service 10. Reboot the system 11. Once system is available, check active profile # tuned-adm active Current active profile: oracle 12. Verify kernel.shmmax value: # sysctl -a | grep kernel.shmmax kernel.shmmax = 4294967295 Due to the oracle profile being the active profile, kernel.shmmax should of been set to 4398046511104 not 4294967295. The same issue happens with kernel.shmall where the value set in my profile is not used and default system value is used instead. This issue only happens during a reboot and I do not see it happen during a stop and start of the tuned service. I'm attaching the files script.sh and tuned.conf that reside within the oracle profile directory.