scott@DSG.Tandem.COM (Scott Hazen Mueller) (03/02/91)
About once every three weeks, the mountd process on our main NFS file server dies; more specifically, inetd kills it off, and logs the following message: inetd[16462]: rpc/udp server failing (looping), service terminated Has anyone else seen this? I'm trying to determine if it's a generic mountd or inetd problem, or if it's specific to the implementation that we're running. If I had to hazard a guess, I'd say that I'm seeing a burst of requests to mountd, and that inetd is mistaking a 'normal' momentary overload as a failure in the mountd process. Since we run automounters on the clients, it is quite possible that we would see such request bursts. -- Scott Hazen Mueller +1 408 285 5762 scott@dsg.tandem.com Tandem Computers VLSI, Unix System Administrator (apple|sun)!tandem!wizard!scott
jik@athena.mit.edu (Jonathan I. Kamens) (03/02/91)
(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