Comment 9 for bug 293000

Colin, thanks for the reply. Maybe I got a wrong impression ;-)

After seeing the issue show up again and again over the last two years, my suggestion would be to change the oom_adj patch itself to set the child oom_adj value always to zero, independent of the value that it was called with.

I understand that the current behavior gives more freedom, but it's not obvious enough, how it works. Basically in the current implementation every caller needs to be aware of it's own oom_adj value which means there is some logic required before starting sshd. We can probably never be sure that the author of every startup script knows what to do. I've seen the problem in Jaunty where a network startup script had oom_adj equal to -17 which was not reset (bug #390556) and now even you made the mistake.

I also cannot imagine any reasons why somebody would need a sshd child oom_adj value different than zero.