># > On Fri, 5 Apr 1996, Phil Knaack wrote:

[ incidently, i didn't write the paragraph below. the lines the above refers
  to weren't included. ]

># > Try doing an "unlimit maxproc" (in csh) before running the forker... With
># > maxproc limited to 80 (the default, apparently), I got the same results as
># > you did. But "unlmit maxproc" raised the limit to 532, which made the
># > forker panic my machine with a "vm_map_entry_create: out of map entries". 
># > This is on a P5/100 with 48M ram, although it did the same thing when I 
># > had 16M...

>#   Root could use the limit -h to prevent this. Limit -h sets the upper 
>#   limit for the limits. 

>This is a band-aid, though.  You should not be able to panic the system
>like this.

>"unlimit maxproc" should, at worst case, raise the proc limit to the max
>USER procs with which the system is prepared to deal, and once the process
>limit is reached, the system should definitely be refusing process creation,
>not panic.

	Agreed. While I couldn't seem to crash my work P5/90 with this little
devil, I was able to quite nicely bring my 486slc2/66 16M machine down to
its knees (and flip it over on its back) very quickly.

	I was in pcvt, and ran this program; the next time the load average
display on the bottom line updated the load was 96. The next update after that
it displayed well over 150, and it didn't make another update because shortly
after that it dropped into the debugger. I could only sync and boot.

	This was running as non-root, too.. interesting. My limits must be
set differently.

Cheers,
Phil
--
Phillip F Knaack               flipk@iastate.edu
Database Programmer, NCREMP    Student Development Group
ISU Extension                  Project Vincent, Iowa State University