On Wed, Jan 27, 2010 at 10:35 AM, Robert <info...@die-optimisten.net> wrote: > frantisek holop wrote: >> >> the kernel will kill random processes? are we talking about linux's OOM >> here or openbsd? since when is this in openbsd? i seem to recall >> some debate where openbsd devs found that idea ridiculous. i know i do, >> and the machine should panic instead of starting shooting down processes. >> >> -f > > Am I missing something here? > If the OS runs out of (any) memory then there is already a serious problem. > In such a case I would prefer that the kernel kills some random applications > but protects itself, so that I can login on the console and check what's > going on. It might even be possible to make a clean reboot (avoiding a long > fsck). > A kernel panic is IMHO the worst option.
Why kill random processes that may not be misbehaving and/or cause a kernel panic when you want to kill the process(es) that leak memory or are hungry in the first place? It's possible to avoid kernel panics in this case IMO, and not kill random processes. When starting daemons (and other stuff you suspect can be hungry), you can use the shell's 'ulimit' to tell the kernel to kill the process should it try to allocate more memory than you think it needs. look up setrlimit(2) The 'chpst' utility from the 'runit' package or 'softlimit' from daemontools is more convenient for this purpose than the shell. Many, if not most people run their daemons without memory limits though.
