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.