Greg A. Woods writes:

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

Because I did not have superuser privileges, of course.

>> 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.

It is not really feasible on Unix to restrict users in a way that
the accumulated memory of all their processes does not fill up system
resources.  You'd need something like per-user virtual memory limits,
like on, for example, VMS, which is not typically available in Unix
(and not in NetBSD either, from what I understand.)  Restricting the
maximum number of processes and individual process size limits so that
the product will never exceed a desired global per-user limit gives
you either very few processes only, or very low memory limits per
process, or both.

>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

Just for the records, I have reported this as kern/7714 in 1999.
The PR is still open and I don't think there really is an easy solution
to this.  I'll try it later that week if the problem still persists.

>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.

I agree here but with ordinary Unix resource control this isn't always
possible to guarantee.

--mkb