On Wed, 19 Oct 2005, Wolfpaw - Dale Corse wrote:
> Heya :)
>
> >
> > well, I don't know about BSD in general, but just try it with
> > OpenBSD. If the machine is generally capable of this task
> > (has the mem and power to suppert n sessions in parallel),
> > it's just your task as admin to make it happen. The means are
> > there. If your users bring down your machine it's most
> > probably your own fault.
>
> You may well be right, though I would say that the amount of
> Code changes users would be required to do, to make it work
> Would end up in my lap, seeing as there are some things OpenBSD's
> Kernel does not have, or has fairly out of date versions of
>
> One example I can think of is libpcap - and it seems to be
> Lagging behind more because some folks are upset that the devs
> There won't accept their commits, then actually fixing the software.
Either submit complete bug reports or diffs, but stop whining.
> Perhaps I will port it .. And see how many people yell at me for
> That. :)
We have good reasons not to blindly follow changes in libpcap.
> Resource use in general was the problem - you can't lock them down
> entirely, because the progs use 99.9 CPU when starting, then settle
> to 2 or 4.. So using something like lshell, or equiv. Doesn't work
> very well. I use a prog that simple snaps a picture of the proc
> table every half hour, and kills things that are over their limit
> for 2 runs. Problem comes into play when a user starts say .. 50
> Copies of the same thing, because it didn't boot.. They just keep
> hitting the button .. :( .. Something Kernel level has saved the
> box from dying many times.
I don't know lshell, but did you try the standard resource limit
facilities that can be set up using login.conf?
Again, submit complete bug reports and please stop talking vague. If
you find something is wrong supply us with hard facts, so we have some
clue what your problem is.
-Otto
