Re: [PATCH] oom killer (Core)
From: Helge Hafting
Date: Sun Dec 05 2004 - 16:09:35 EST
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/