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.
Bug 1458916 - SHM* Sysctls were not increased for s390 systems
Summary: SHM* Sysctls were not increased for s390 systems
Keywords:
Status: CLOSED DUPLICATE of bug 1493069
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: initscripts
Version: 7.4
Hardware: s390
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: David Kaspar // Dee'Kej
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks: 1420851 1465901 1466365 1549689
TreeView+ depends on / blocked
 
Reported: 2017-06-05 20:04 UTC by Charles Haithcock
Modified: 2020-09-10 10:40 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-27 13:27:40 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Charles Haithcock 2017-06-05 20:04:38 UTC 
Description of problem:

shm* sysctls were introduced to lower the shm* sysctls for the system to lower values but were removed in later releases except for s390 systems. 


Version-Release number of selected component (if applicable):

RHEL 7.2-3 

How reproducible:

100%

Steps to Reproduce:
1. Install RHEL 7 onto an s390 system
2. run `sysctl -q kernel.{shmmax,shmall}` and check `grep shm /usr/lib/sysctl.d/00-system.conf`


Actual results:
[root@gss3 ~]# sysctl -q kernel.{shmmax,shmall}
kernel.shmmax = 4294967295
kernel.shmall = 268435456

[root@gss3 ~]# grep shm /usr/lib/sysctl.d/00-system.conf 
kernel.shmmax = 4294967295
kernel.shmall = 268435456



Expected results:
[root@gss3 ~]# sysctl -q kernel.{shmmax,shmall}
kernel.shmmax = 18446744073692774399
kernel.shmall = 18446744073692774399

[root@gss3 ~]# grep shm /usr/lib/sysctl.d/00-system.conf -c
0


Additional Info:
Relevant BZs introducing the shm increases and rollbacks to shm* sysctls:
 - BZ1056547: also contains motivation for rollback in comment 15
 - BZ1150130: introduction of shm* being set to ULONG_MAX - 2^24
 - BZ1222403: backport sysctl rollback to 7.1
 - BZ1101821: 7.1
Comment 3 Lukáš Nykrýn 2017-06-06 12:16:19 UTC 
I am not sure it would be wise to change the defaults. And you can easily override this through another sysctl.d drop-in.

Anyway let's move this decision to 7.5 since we already passed beta.
Comment 4 Charles Haithcock 2017-06-06 16:31:25 UTC 
(In reply to Lukáš Nykrýn from comment #3)
> I am not sure it would be wise to change the defaults. And you can easily
> override this through another sysctl.d drop-in.
> 
> Anyway let's move this decision to 7.5 since we already passed beta.


Thanks for that correction, I seemed to have missed that. 

For the defaults, I (potentially incorrectly) assumed the same should be done for s390 systems since we rolled back the sysctls for other arches. If we need to keep the sysctls where they are for s390 systems, then we of course can, but we will need the reasoning mentioned somewhere. From there, I can open a BZ with the docs team as our docs currently make no indication or warning about the difference between s390 systems and otherwise.
Comment 5 David Kaspar // Dee'Kej 2017-06-06 19:53:01 UTC 
(In reply to Charles Haithcock from comment #4)
> For the defaults, I (potentially incorrectly) assumed the same should be
> done for s390 systems since we rolled back the sysctls for other arches. If
> we need to keep the sysctls where they are for s390 systems, then we of
> course can, but we will need the reasoning mentioned somewhere. From there,
> I can open a BZ with the docs team as our docs currently make no indication
> or warning about the difference between s390 systems and otherwise.

Hello Charles,

we were discussing this today, and none of us remember why that configuration wasn't also removed for s390x. We have come to 2 conclusions:
1) Either this is a mistake on our side that we forgot to remove that configuration, or
2) it was left there intentionally for some reasons we are not aware ATM (we are no experts on s390x).

As a result, we have decided to postpone the final decision what to do about this, and during that time we will try to reach out to IBM people to consult this with them.

Anyway, in the meantime, you can use workaround as suggested by Lukas... ;)

Best regards,

David
Comment 6 Charles Haithcock 2017-06-07 13:03:17 UTC 
> 1) Either this is a mistake on our side that we forgot to remove that
> configuration, or
> 2) it was left there intentionally for some reasons we are not aware ATM (we
> are no experts on s390x).


Understood; I had the same thoughts as well. 


> As a result, we have decided to postpone the final decision what to do about
> this, and during that time we will try to reach out to IBM people to consult
> this with them.


Sounds good! 

 
> Anyway, in the meantime, you can use workaround as suggested by Lukas... ;)


Absolutely; my customer is fine with simply putting in a custom sysctl.conf file. Fortunately this is not a huge deal for them (as it shouldn't be).
Comment 11 David Kaspar // Dee'Kej 2018-04-27 13:27:40 UTC 
The pull-request to resolve this has been submitted:
https://github.com/fedora-sysv/initscripts/pull/182

We have other BZ for tracking this issue, so I'm closing this one as a duplicate.  If you need to follow up with more information, please do so in BZ #1493069...

 -- David --

*** This bug has been marked as a duplicate of bug 1493069 ***
Note You need to log in before you can comment on or make changes to this bug.