Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!icdoc!qmw-cs!liam
From: liam@cs.qmw.ac.uk (William Roberts;)
Newsgroups: comp.unix.aux
Subject: Re: Increasing the number of processes
Keywords: processes kconfig
Message-ID: <3055@redstar.cs.qmw.ac.uk>
Date: 17 Apr 91 16:27:58 GMT
References: <1991Apr11.002937.2503@agate.berkeley.edu> <51433@apple.Apple.COM>
Sender: usenet@cs.qmw.ac.uk
Lines: 40
Nntp-Posting-Host: whitesand

In <51433@apple.Apple.COM> antonio@Apple.COM (Antonio Ordonez) writes:

>I increased the values for both variables in my system and both work as 
>expected.  He was getting an error 
>
>"No more processes" or "Killed" when trying to execute a program.
>
>If you were running out of entries in the process table the kernel 
>error message would go to the console and give you  
>
>"proc: table is full"
>
>In his case the problem was that he was actually running out of 
>entries in the memory regions table. The reason why the errors weren't 
>seen is that the scripts that he is using to start X11 don't redirect
>the error messages intented for the console to the X11 console.

Ah-ha! Now we're getting somewhere. The message "no more processes" is the 
traditional mis-leading message associated with error EAGAIN - if you exceeded 
your per-user process limit it should give EPROCLIM and a message "too many 
processes".

The comment about redirecting the console is true but unhelpful. NO CONSOLE 
MESSAGE IS GENERATED for filling the regions table, if that is indeed what has 
happened. I get this kind of message a lot when trying to do thing like make, 
gcc and so on under a 32-bit session: I'm running startmac -m8m on a Mac IIcx 
with  4 Meg of real memory but about 11 Meg of swap (swap -l says 23248). 
Running X11 instead permits make, gcc etc to work, so there must be something 
related to that shared memory segment...

Perhaps you could follow-up some more and tell us:

a) what resources associated with *physical* memory can cause fork or sbrk
   to fail returning EAGAIN?
b) what kconfig options can be used to adjust this?
c) what additional implications there are in all this if shared memory 
segments are used?

I'd have SPR'd this a long time ago, but it isn't too easy to send you 
something to duplicate it with.