flanagan@batcomputer.tn.cornell.edu (Doug Flanagan) (12/04/86)
O.K. I give up. What the heck does "Text: table is full" mean?
We are running Sun 3.0 on a Sun 3/160 server and on four Sun 3/50's.
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.
The message is triggered by the initiation of a process, which
is aborted immediately, whether it be a "man" or a shell or whatever.
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.
Anyone know what's going on? It is really annoying when it starts
happening! You can't anything done.
Thanks.
Douglas Flanagan
Systems Whatever
Newman Lab. of Nuclear Studies
Cornell U., Ithaca, N.Y. 14853
(607) 255-5354
{decvax,ihnp4,cmcl2,vax135}!cornell!amvax!flanagan (USENET)
flanagan@amvax.tn.cornell.edu (ARPANET)
mlandau@Diamond.BBN.COM (Matt Landau) (12/04/86)
In comp.unix.wizards (article <1698@batcomputer.tn.cornell.edu>), flanagan@batcomputer.tn.cornell.edu (Doug Flanagan) writes: > >O.K. I give up. What the heck does "Text: table is full" mean? > >Anyone know what's going on? It is really annoying when it starts >happening! You can't anything done. > > Douglas Flanagan > flanagan@amvax.tn.cornell.edu (ARPANET) Well, the message means that a kernel table has overflowed, presumably because there are more people (== more processes) on your machines. We had the same problem with our fileservers when people started trying to use them for real work at the same time as they were servicing diskless clients. If you look in /usr/sys/conf/param.c (which you get even with non-source distributions), you'll see that ntext, the number of entries in the text table, is set to 24 + MAXUSERS. The obvious solution is to reconfigure your Unix kernel with a larger value for MAXUSERS. However, this will increase the size of a number of other kernel tables, sometimes quite a bit. (Nclist, for example, is based on 16 * MAXUSERS.) If you don't like that idea, just copy param.c into the directory used to make your kernel and change the calculation for ntext to something more appropriate. -- Matt Landau BBN Laboratories, Inc. mlandau@diamond.bbn.com 10 Moulton Street, Cambridge MA 02238 ...seismo!diamond.bbn.com!mlandau (617) 497-2429
chris@mimsy.UUCP (Chris Torek) (12/04/86)
In article <1698@batcomputer.tn.cornell.edu> flanagan@batcomputer.tn.cornell.edu (Doug Flanagan) writes: >O.K. I give up. What the heck does "Text: table is full" mean? It means the text table is full. (The text table is an array that holds information about program texts. Every program you run takes one slot; running the same program many times simultaneously still takes only one slot.) The fix is to increase the size of the text table, which is best done by configuring a new kernel with a larger `maxusers' parameter. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu
ji@garfield.columbia.edu (John Ioannidis) (12/04/86)
In article <1698@batcomputer.tn.cornell.edu> flanagan@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@cs.columbia.EDU USnail: John Ioannidis ji@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@cs.columbia.EDU USnail: John Ioannidis ji@garfield.columbia.EDU 450 Computer Science Columbia University, USENET: ...{seismo|topaz}! New York, NY 10027 columbia!garfield!ji ... It's all Greek to me!
sow@luthcad.UUCP (12/07/86)
In article <1698@batcomputer.tn.cornell.edu> flanagan@batcomputer.UUCP writes: > >O.K. I give up. What the heck does "Text: table is full" mean? > >The message is triggered by the initiation of a process, which >is aborted immediately, whether it be a "man" or a shell or whatever. >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. > I got the same problem when I installed MH on my machine. I think that you have some programs with the save text bit set (chmod +t), this mode saves the text segment so it will not help to kill some processes. The solution is to do a chmod -t on "all" files, and then reeboot the system. Sven-Ove Westberg UUCP: sow@luthcad.UUCP UUCP: {decvax,philabs,seismo}!mcvax!enea!luthcad!sow