flanagan@batcomputer.tn.cornell.edu (Doug Flanagan) (12/06/86)
Many thanks to the many people who responded to my question about the "Text: table is full" message. All the information about param.c (provided even to binary only customers by Sun), MAXUSERS, pstat -T, etc. was very helpful. However, I think Guy Harris may have hit our problem on the head. At the end of his letter to me he states: From: guy@Sun.COM (Guy Harris) However, there could be another problem. If you're fetching your programs over NFS, there's a bug in 3.0 that causes text table entries to get lost if the server doesn't respond in time when the last process using an executable image exits or otherwise ceases to use it. Unfortunately, the only workaround is to reboot the machine; this bug is fixed in 3.2. The reason I believe this to be a part of our problem is this: When I first started to see the message "Text: table is full" on one of the 3/50's yesterday, I ran pstat -T and saw that 26 of 28 slots were used. A "man pstat" was enough to cause the message to generated again. I killed off user's processes one by one and gained 1 slot for every process killed. When I was down to where the only processes left were the ones started during a full boot, plus my own csh, there were still 23 of 28 slots used. I rebooted the machine, logged in, and only 11 of 28 were used. I must admit that I have not helped our server's response time. Since our Vax went out the door, I have had to do most of my own work directly on the server. But next week I will be installing an Eagle and four more 3/50's, and I won't have to use this Zenith any more! Thanks again. 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)