Re: [PATCH] oom killer (Core)

[Helge Hafting <helgehaf@aitel.hist.no>]

On Fri, Dec 03, 2004 at 10:20:22PM +0100, Thomas Gleixner wrote:
> On Fri, 2004-12-03 at 15:41 +0100, Helge Hafting wrote:
> > The case of OOM killed sshd is fixable without touching the kernel:
> > Make sure sshd is started from init, init will then restart sshd whenever
> > it quits for some reason.  This will get you your essential sshd back
> > assuming the machine is still running and the OOM killer managed
> > to free up some memory by killing some other processes.
> > 
> > One might still wish for better OOM behaviour, but it is a case
> > where something has to give.
> > 
> 
> Hey, are you kidding ?
> 
Please don't misunderstand.  I'm not saing that 2.6 is fine,
only that there is a way to automatically restart a sshd accidentally 
killed by the OOM killer.  This could probably save you some of those
trips, if you keep experimenting with 2.6.

> 2.4 lets me not in, because the fork of sshd fails. How do you fix this
> with changing the userspace ?
> 
Fork failing is another issue than a killed sshd.  It is usually fixed
by using ulimit so a buggy process simply cant fork off way too
many children. (Or use up too much memory.)

> 2.6 oom is plain buggy
> 
Quite possible, but be aware that these things can happen with 2.4 too.
It is possible to get 2.4 into a shortage where fork fails,
you should use ulimit anyway to avoid that.  Also, having
a sshd that is restarted by "init" is a good idea anyway
on such a remote machine.  2.4 might not kill sshd by kernel bug, but
who knows what some future exploit or future bug could do. 

> I have no problem to help myself, but I want to get this fixed in a
> reliable way which meets the comment in oom_kill.c: "least surprise"

I too want a well-behaved OOM killer.  Workarounds are available though,
until this happens.

Helge Hafting