bill@wrangler.WLK.COM (Bill Kennedy) (04/27/91)
I have encountered two different anomalies with Interactive NFS, I am not sure that they are related, so I will describe them separately. This machine, wrangler, is an NCR Tower 32/400 running their NFS which is known to work with other NCR boxen and Suns. The other machine, ssbn, is running ISC 2.2 with the 2.1 NFS. By and large it works OK but I noticed that some of the utilities on the NCR would create a flood of portmap processes on the '386. I attributed that to some kind of bug in Wollongong (NCR) stuff, all in all it's more high strung than Lachman. While working with my vendor to try and track down the problem I brought up a second ISC machine similarly configured (except for the 1-2 user license, I only bought one unlimited license). I ran an rpcinfo on the second '386 and the same flood of portmap processes appeared on ssbn until the process table filled up and it was big red switch time. Since both the NCR and another '386 can cause the phenomenon I have to take back my unkind remarks about NCR's NFS. The symptom is much worse coming from another ISC system than from the NCR. The command I used was rpcinfo -b 100003 2 Which is supposed to broadcast and find out what hosts on the network have NFS version 2 registered. What actually happened was that carpet (the one sending the broadcast) got umpteen answers from ssbn and ssbn's proc table filled to capacity with portmap processes. I'm just going to guess that ssbn's portmap daemon got in a loop and forked itself to death. Realizing that unless you run out of queues or something before your proc table fills up, you're going to have to reset to recover; can anyone else reproduce this? Has anyone noticed anything similar? I'll post another article with the other anomaly, I'm pretty sure they are completely unrelated. -- Bill Kennedy uucp {att,cs.utexas.edu,pyramid!daver}!ssbn.wlk.com!bill internet bill@ssbn.WLK.COM or ssbn!bill@attmail.COM