Messages in this thread | | | Date | Sun, 5 Dec 2004 22:14:43 +0100 | Subject | Re: [PATCH] oom killer (Core) | From | Helge Hafting <> |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |