Sun 3.0, Text: table is full

[John Ioannidis]

In article <1698 at batcomputer.tn.cornell.edu> flanagan at batcomputer.tn.cornell.edu (Doug Flanagan) writes:
>
>O.K.  I give up. What the heck does "Text: table is full" mean?

The text table is where the kernel keeps track of which `pure' (i.e., 
shareable) executables are already loaded (so that there is only one
copy of, say, emacs in the virtual memory.) If you try to run more
programs than there is space for, the kernel will complain!
You can find how many text table entries you have by doing a pstat -T.
You can also check /sys/conf/param.c; in my machine, it's
ntext = 24 + 2 * MAXUSERS. (=28). 

>We never saw this message on any of the machines for many months,
>but then we sold our Vax and the load on each diskless machine increased from
>one user to three. Then we started seeing this message on just one of
>the 3/50's. Then later I got it on the 3/160. Now another 3/50 is
>doing it. I have looked at vmstats, perfmeters, ps's and on and on,
>and have not located the cause. We do not have source, but based on
>"strings vmunix" I believe the message comes from the kernel.
>It is always written to the console and syslog only.

BTW, even if you don't have sources, you should still be able to change
that line in param.c and recompile the kernel. See if that helps.
>
>Rebooting the machine will make the problem go away for a while, but
>it eventually comes back. Killing off processes and reducing the 
>machines load doesn't always seem to help either. Acutually, the
>machines load average is usually fairly low. Shutting down suntools
>and reducing memory requirements doesn't seem to help either.
>

There might be another explanation: You run programs which fork off 
other processes and don't wait(2) for them to die. When this happens,
the child processes become zombies (<EXITING>) only to be inherited by
init(1) when the parent dies. When this happens (this is obviously a 
bug, but I cannot pinpoint it) the text table entry is not freed.

I had stumbled on that bug a couple of weeks ago; the solution is to 
have the parent catch SIGCHILD and do an actual wait(2) to clean up.
Using wait3(2) to do non-blocking wait didn't seem to work. Of course,
I might be missing something.

Has anyone else had a similar problem? I haven't dared check it on 
our Vaxen (we run 4.3BSD), but it's there on 2.0 and 2.2 Sun Unix.



#include <appropriate_disclaimers>

VOICE: 	+1 212 280 5510			ARPA: ioannidis at cs.columbia.EDU
USnail:	John Ioannidis			      ji at garfield.columbia.EDU
	450 Computer Science
	Columbia University,		USENET: ...{seismo|topaz}!
	New York, NY 10027			   columbia!garfield!ji

			... It's all Greek to me!
#include <appropriate_disclaimers>

VOICE: 	+1 212 280 5510			ARPA: ioannidis at cs.columbia.EDU
USnail:	John Ioannidis			      ji at garfield.columbia.EDU
	450 Computer Science
	Columbia University,		USENET: ...{seismo|topaz}!
	New York, NY 10027			   columbia!garfield!ji

			... It's all Greek to me!