* Bjoern Fischer <[EMAIL PROTECTED]> [000411 10:06] wrote:
> On Mon, Apr 10, 2000 at 01:31:39AM -0700, Alfred Perlstein wrote:
> [...]
> > > main(){fork();main();}
> > >
> > > leaves the machine in an unusable state (it does ping
> > > back, one may break into the kernel debugger, but no
> > > io).
> > >
> > > Any way to prevent this (without harming the user)?
> >
> > Please reread the documentation on limits.
> >
> > cputime unlimited
> > filesize unlimited
> > datasize 256MB <-
> > stacksize 64MB <-
> > coredumpsize unlimited
> > memoryuse unlimited
> > memorylocked unlimited
> > maxproc 4115
> > descriptors 8232
> > sockbufsize unlimited
> >
> > If appropriate limits are in place and you still get problems
> > then let us know.
>
> Already set:
>
> ...
> datasize 1048576 kb
> stacksize-cur 16384 kb
> ...
>
> Some more information: This happens on a diskless client (265MB RAM,
> lots of swap (1.2G) on the server). When I limit the stacksize to 3MB,
> all fork-processes fit into RAM and the situation is recoverable
> with some effort and `/usr/bin/killall' (Eww, that's a perl script).
>
> With a stacksize limit of 16M 64 fork processes sould easily fit
> into swap, so I don't think it is an out-of-swap situation.
>
> Listening to the ether on the server, I realized heavy RPC traffic
> (swapping, probably) and then silence. Any idea how to find out,
> whether swap in not really full, the client won't answer but maybe
> looking for some kind of NFS write errors or something?
>
> As this is a strange setup (1.2G swap via NFS) this issue
> in not critical at all.
It's also silly. If you've found limits that "work" then why insist
on giving your users enough rope to hang you?
Either enforce proper limits or rmuser.
If you could get a traceback of the stuck client, that would be
helpful.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
"I have the heart of a child; I keep it in a jar on my desk."
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
