Bug 1010429

Summary: Openssh Incorrectly sets oom_adj in all Children after Performing a Reload
Product: Red Hat Enterprise Linux 6 Reporter: mife1 <deleriux1>
Component: opensshAssignee: Petr Lautrbach <plautrba>
Status: CLOSED ERRATA QA Contact: Stanislav Zidek <szidek>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.5CC: ksrot, plautrba, pvrabec, rupatel, szidek, todayyang, tommi.tervo
Target Milestone: rcFlags: rupatel: needinfo+
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: openssh-5.3p1-96.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1130202 (view as bug list) Environment:
Last Closed: 2014-10-14 07:39:13 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1070830, 1130202    
Attachments:
Description Flags
Restore the initial oom_adj value prior to re-execing on HUP.
none
Restore the initial oom_adj value prior to re-execing on HUP.
none
Restore the initial oom_adj value prior to re-execing on HUP. none

Description mife1 2013-09-20 18:49:22 UTC
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.

Comment 2 mife1 2013-09-22 21:55:36 UTC
Created attachment 801394 [details]
Restore the initial oom_adj value prior to re-execing on HUP.

This patch is reworked to be more compatible with the openssh design philosophy, it is similar to the one accepted upstream.

Comment 3 mife1 2013-09-23 09:27:35 UTC
Created attachment 801553 [details]
Restore the initial oom_adj value prior to re-execing on HUP.

Fix typo

Comment 4 RHEL Program Management 2013-10-14 02:02:27 UTC
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 5 mife1 2013-11-28 17:21:20 UTC
The problem remains in the newest openssh-server build from 6.5

Comment 7 Karel Srot 2014-03-28 07:51:42 UTC
Petr,
could you please confirm that this is different from bug 1071290?

Comment 10 Petr Lautrbach 2014-06-13 12:58:37 UTC
*** Bug 1071290 has been marked as a duplicate of this bug. ***

Comment 13 Petr Lautrbach 2014-06-17 11:28:38 UTC
Thanks for the patch, it will be applied in the next update.

Comment 17 errata-xmlrpc 2014-10-14 07:39:13 UTC
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.

http://rhn.redhat.com/errata/RHSA-2014-1552.html