🚀 go-pugleaf

In article <1ej08nINNdrn@menudo.uh.edu> sears@tree.egr.uh.edu (Paul S. Sears)  
writes:
> This sounds like the problem we were having here for awhile.  First, do a "ps  
> -aux" on your servers when your clients get the NFS server not responding  
> message.  See which process is using up the most cpu.  My hunch is that  
> lookupd might be the culprit.  It this is indeed the case, then your problem  
> most likely involves netgroups, if you are using them.  Please post more  
> information about your problem.

Yes, I am using a netgroup for restricting NFS access to our local bunch of
machines (4 NeXTs and a few PCs). Also the NeXTs have root NFS access.

> When the server panicked, there should have been a reason for the panic in  
the  
> little window.  It is very helpful to post the panic messages so we have a  
> better idea of what was going on.  

The problem with the panic messages is that they scroll by so quickly :-(
But I remember that it reported something like 'ns_abstimeout table overflow'
as the cause of the panic (this was the 3.0 host). I think it is also
interesting that it said 'NFS server ruble ok' (the 2.1 host), immediately
after the 'Killing all processes' message - looks to me like some sort of
deadlock which can only be broken by killing the right process.

	Rainer
--
Rainer Staringer                   | rainer@fml.tuwien.ac.at
Financial Markets Lab, TU Vienna   | +43 (1) 58801/8138