Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
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
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.