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.
Created attachment 800620 [details] Restore the initial oom_adj value prior to re-execing on HUP. Description of problem: SSHD attempts to eliminate its chances of being killed by the OOM killer through manipulation of the oom_adj values in /proc for itself at startup. To do this two functions are used. oom_adjust_save and oom_adjust_restore. oom_adjust_save reads (and saves) the current value for this parameter before setting it to -17, this is called during startup when sshd has 0 as its initial oom_adj property. oom_adjust_restore places the saved value back into the process' oom_adj property. This is called after fork()'ing a new ssh process in order to make sure the child process does not keep -17 when running an interactive session. However, on SIGHUP, openssl re-execs itself, re-initializing. Now, when sshd calls oom_adjust_save the value *is already* -17 (inherited from its previous instance) and when children are thus spawned oom_adjust_restore restores -17 into their oom_adj scores, which is subsequently inherited by all children of the sshd session created. Thus any remote login sessions processes after a reload are never going to be selected by the oom-killer. Version-Release number of selected component (if applicable): This problem was tested on openssh-server-5.3p1-84.1.el6.x86_64 and in Fedora openssh-server-6.2p2-5.fc19.x86_64. How reproducible: Every time. Steps to Reproduce: 1. Login to a host via ssh. 2. Check your oom_adj score by doing: cat /proc/self/oom_adj 3. Reload sshd on the host. 4. Login again to this host with ssh. 5. Check your oom_adj score by doing: cat /proc/self/oom_adj Actual results: The oom_adj score is -17 for any new session on the host. Expected results: oom_adj score would normally be 0 for any new session. Additional info: A patch is attached built against openssh-server-5.3p1-84.1.el6.x86_64 which rectifies the bug by restoring the initial oom_adj value prior to re-execing on HUP.