Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!execu!sequoia!balkan!wrangler!ssbn!bill
From: bill@ssbn.WLK.COM (Bill Kennedy)
Newsgroups: comp.unix.sysv386
Subject: Re: ISC RPC NFS v1.2 rexd
Summary: SL/IP was the culprit
Keywords: NFS RPC rexd
Message-ID: <2061@ssbn.WLK.COM>
Date: 29 Apr 91 14:14:26 GMT
References: <677@wrangler.WLK.COM>
Distribution: na
Organization: W.L. Kennedy Jr. & Associates, Pipe Creek, TX
Lines: 43

In article <677@wrangler.WLK.COM>, I wrote:

[ problems with rexd exiting prematurely and generally antisocial
  behavior with NFS running ... ]

Jim Deitch (jdeitch@jadpc.cts.com) encountered (and reported without
acknowledgement) the same problem and here's the workaround.

If SL/IP is configured and up before NFS starts rexd will behave as
described in my original article.  To make rexd behave you must either
comment it out of /etc/netd.cf and start it by hand with ifconfig after
you start NFS or you must ifconfig it down, start NFS and ifconfig it
back up.

I think that ISC deserves a twist of the tail for this.  It's just a
nuisance, easily worked around, but they certainly should have ack'd
Jim's report when they got it.  Maybe they'll acknowledge the problem
if the workaround is posted to the net.

In article <676@wrangler.WLK.COM>, I wrote:

[ runaway portmap processes when receiving an rpcinfo broadcast ... ]

This was confirmed by several people and ISC says it will be fixed in
the next release (do we need a FITNR acronym?).  There's a clumsy
workaround but just avoid rpcinfo broadcasts if you can.  The workaround
is to have a small enough number of queues (NQUEUE) allocated so that
you'll run out of queues before you run out of process slots.  The portmap
processes are rather easily killed -9 when it happens if you have a
process slot left to fork off a kill.  If you do get jammed up such that
you can't fork off a kill and you know the parent portmap PID you can
exec a kill and log back in.

I got one response saying that the phenomenon vanished as suddenly and
mysteriously as it appeared after he recompiled portmap.  I don't know
if he's referring to the XDR source in section 5.7 of TFM or portmap.c
but I'll type in the XDR source and a kind soul sent me a portmap.c,
I'll try each and report if either/both produce the desired result.  If
it does I guess we don't need FITNR or at least those of us on the net
don't...
-- 
Bill Kennedy  internet  bill@ssbn.WLK.COM or ssbn!bill@attmail.COM
              uucp      {att,cs.utexas.edu,pyramid!daver}!ssbn.wlk.com!bill