On Mon, 13 Mar 2000, Peter T. Breuer wrote:
> "A month of sundays ago James Sutherland wrote:"
> > At the time, I suggested moving the grim-reaper code into a userspace
> > daemon, to allow much greater/easier configurability. I can think of a few
>
> I believe this is the correct solution. It implies exactly _one_
> privileged task, whose job is to decide the privileges of all the rest.
Yes.
> > For the time being, though, the simple "kill the most likely suspect"
> > patch should be a pretty good approximation.
>
> Nope. It isn't. It's unacceptable in practice.
It's better than the current system, which amounts to "kill processes at
random until there's some free memory again."
> I run labs. The lab machines have to have defenses against
> _themselves_. First line defence: system daemons restarted by
> init if killed. Second line: daemons restarted by cron-based checks
> (cron has to be maintained from init) at regular intervals. Third
> line: software watchdog checking mem use and ready to pull machine
> to runlevel s and back up again if conditions not rectified.
If your watchdog monitors memory usage and corrects problems, then the
kernel OOM handler will never be invoked.
I want to emphasise this point: the OOM handler should **NEVER** be
invoked. If it is ever needed, there is something BADLY wrong with the
system - either we do something drastic (process slaughtering) or the
machine goes down completely. Worrying about which user processes are
killed to avoid an uncontrolled failure is a case of rearranging the
deckchairs on the Titanic.
> Even so, I get reports every couple of days from machines that
> have obviously killed themselves. I just got one from a cron
> telling me it had restarted the software watchdog, for goodness'
> sake! (amongst others: rpc.nfsd and rpc.mountd seem to be favourites).
If your watchdog is dying, then you have some big problems there. Either
it is killing itself for some reason, or you have *very* big problems with
the other software, or the machine's hardware. (Malicious users, perhaps?)
James.
-
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/
This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:26 EST