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.
>
> > 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.
If killing the most likely culprits is unacceptable, how do you view
killing entirely *random* processes??
> 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.
In which case, this final failsafe behaviour (in the event that the kernel
is COMPLETELY unable to allocate ANY memory) will never hit you - unless
this third line of defence fails, in which case you are pretty much SOL
with the current kernel.
> 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).
In which case, this patch is unlikely to affect you - unless your memory
watchdog fails in conjunction with another process exploding. At this
point, current kernels effectively go into a killing spree and kill
entirely random processes; patched kernels start killing the
likely-looking culprits.
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:24 EST