Re: The /tmp and modules_install saga

owner-linux-kernel@vger.rutgers.edu
Wed, 07 Oct 1998 08:33:28


-0000=?us-ascii?Q?_(/etc/localtimep=97=12=08|=F7=FF=BF=3Dm =08?=
Reply-To: peterw@dascom.com
From: Peter Waltenberg <peterw@dascom.com>
To: linux-kernel@vger.rutgers.edu
Subject: OOM killer
X-Orcpt: rfc822;linux-kernel@vger.rutgers.edu
Sender: owner-linux-kernel@vger.rutgers.edu
Precedence: bulk
X-Loop: majordomo@vger.rutgers.edu

For the machines that are essentially single user desktop machines, running out
of memory is no big deal. Reach down and press reset :).
However, the more commercially important uses of Linux are server boxes, and
these will be quite often unattended, and more importantly, they may die at 3am.

Given the choice of having the machine locked up and having to drive 20 miles to
reset it at 3am , or having a few apps being killed and being able to log in
remotely and restart them, I know which I'd prefer.

With all due respect to the people who are trying to keep Linux alive when some
process runs wild and eats the machine, I don't think you'll suceed totally with
this approach no matter what you do.

At some point something or someone has to decide enough is enough and start
picking processes to kill. As people have demonstrated, if we don't solve the
problem random processes die anyway AND the machine locks up.

Personally I'd prefer non-random processes dying and the machine remaining
usable, particularly if the processes killed are logged.

Even something simple like "kill most recent processes first" will kill Netscape
before it kills X.

If it's possible to enable/disable this on the fly I can't see there's any
reason to not add it, and plenty of reasons why we should.

Peter
----------------------------------
E-Mail: Peter Waltenberg <peterw@dascom.com>
Date: 07-Oct-98
Time: 08:17:20

This message was sent by XFMail
----------------------------------

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/