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.
Björn
--
-----BEGIN GEEK CODE BLOCK-----
GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L---(++) !E W- N+ o>+
K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+
------END GEEK CODE BLOCK------
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
