Xref: utzoo comp.protocols.nfs:1856 comp.unix.admin:1116
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!uunet!shelby!snorkelwacker.mit.edu!bloom-picayune.mit.edu!athena.mit.edu!jik
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.protocols.nfs,comp.unix.admin
Subject: Re: rpc.mountd dying
Message-ID: <1991Mar1.180812.9842@athena.mit.edu>
Date: 1 Mar 91 18:08:12 GMT
References: <1991Mar1.173518.13401@tandem.com>
Sender: news@athena.mit.edu (News system)
Organization: Massachusetts Institute of Technology
Lines: 31


  (Note that I have restored comp.unix.admin to the Newsgroups, because this
is more of an inetd issue than an NFS protocol issue.)

  Inetd has a security feature to prevent a particular service from being
overloaded with requests.

  If more than TOOMANY requests for a particular service come in in CNT_INTVL
seconds (in the code I'm staring at, the former is 40 and the latter is 60),
then inetd assumes that either something is looping somewhere or someone is
trying to perform some sort of attack on your machine, and shuts off the
service.

  Therefore, it seems quite likely that if, for example, you boot up fifty
diskless workstations all at the same time and they all boot in sync and try
to mount the same root partition in quick succession, that would cause your
inetd to shut down the rpc.mountd service.

  The fix is to recompile inetd with either a larger value for TOOMANY, or a
smaller value for CNT_INTVL.  Probably, making TOOMANY bigger than the number
of clients that are hosing the machine would solve your problem.  I suspect
you can get the source to inetd from the BSD archive sites if you don't have
it; if not, you can always adb the binary and change the value :-).

  I hope this helps.

-- 
Jonathan Kamens			              USnail:
MIT Project Athena				11 Ashford Terrace
jik@Athena.MIT.EDU				Allston, MA  02134
Office: 617-253-8085			      Home: 617-782-0710