[ On Tuesday, June 12, 2001 at 13:24:43 (+0200), Matthias Buelow wrote: ]
> Subject: Re: ctrl+alt+del
>
> First, there's the problem of administrator not being reachable
> and the workstation is question is hogged by several amok-running
> netscapes, pines etc. (which seems to happen surprisingly often,
> on various systems, although I personally have never been able to
> reproduce it.)  In my case, this was very annoying, since it was
> on small (and slow) Alphas, with rather limited memory and it was
> a serious obstacle to getting work done since not only was the CPU
> busy but also swap was almost filled by the swapped out pages.

Why didn't you just kill the offending processes?  A reboot was not
necessary in that case.

If the system was thrashing beyond recovery and indeed totally
unresponsive, eg. there's more swap space than necessary an limits are
not adjusted to prevent users from using more VM than they should, then
a reboot might be necessary.  However that's a situation that shouldn't
be allowed in the first place.  It's also a case where hitting the reset
button is not really much more risky than a DDB "sync".

> The second problem is with intended malicious user actions, like
> my favourite example of "while :; do grep asdf /dev/zero&; done"
> which usually locks up solid systems like *BSD and Gnu/Linux
> (especially when they're using Gnu grep, which attempts to suck in
> a whole line into memory.)  Users just do such things eventually,
> I know it from first hand experience[1], and you cannot really
> prevent this with user limits.

Yes, actually, you can.  If you couldn't then there'd be no point to
implementing such limits.

Furthermore the "lock-up" is not anywhere near as "solid" as you claim
it is -- indeed I wouldn't even call it a "lock-up"!  I've just tried
this to prove the point on a Sparc-20.  The serial console was actually
still quite responsive.  I logged in and simply killed every process on
the terminal where the offending greps were running after I'd killed the
login shell there.  Of course anyone faced with such a situation has to
be both patient and knowledgeable of appropriate techniques for dealing
with such problems, lest they get trapped into trying to kill the greps
one-by-one and never keeping ahead of whatever's creating them.

>  This might of course also result
> from an unintended situation, simply when the user is doing something
> stupid.

Nothing any unprivileged user does should ever threaten the continued
existance of the system.  If such a threat is possible then there's
either a bug or major design flaw in the system.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>