NFS problems ISC v2.1

[Bill Kennedy]

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 at ssbn.WLK.COM   or ssbn!bill at attmail.COM