home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / sys / next / sysadmin / 6662 < prev    next >
Encoding:
Text File  |  1992-11-22  |  1.8 KB  |  42 lines
  1. Newsgroups: comp.sys.next.sysadmin
  2. Path: sparky!uunet!email!news
  3. From: rainer@ruble.fml.tuwien.ac.at (Rainer Staringer)
  4. Subject: Re: NFS problems
  5. Message-ID: <1992Nov23.080715.3014@email.tuwien.ac.at>
  6. Sender: news@email.tuwien.ac.at
  7. Nntp-Posting-Host: moolah.fml.tuwien.ac.at
  8. Reply-To: rainer@eimoni.tuwien.ac.at
  9. Organization: Technical University of Vienna
  10. References: <1ej08nINNdrn@menudo.uh.edu>
  11. Date: Mon, 23 Nov 1992 08:07:15 GMT
  12. Lines: 28
  13.  
  14. In article <1ej08nINNdrn@menudo.uh.edu> sears@tree.egr.uh.edu (Paul S. Sears)  
  15. writes:
  16. > This sounds like the problem we were having here for awhile.  First, do a "ps  
  17. > -aux" on your servers when your clients get the NFS server not responding  
  18. > message.  See which process is using up the most cpu.  My hunch is that  
  19. > lookupd might be the culprit.  It this is indeed the case, then your problem  
  20. > most likely involves netgroups, if you are using them.  Please post more  
  21. > information about your problem.
  22.  
  23. Yes, I am using a netgroup for restricting NFS access to our local bunch of
  24. machines (4 NeXTs and a few PCs). Also the NeXTs have root NFS access.
  25.  
  26. > When the server panicked, there should have been a reason for the panic in  
  27. the  
  28. > little window.  It is very helpful to post the panic messages so we have a  
  29. > better idea of what was going on.  
  30.  
  31. The problem with the panic messages is that they scroll by so quickly :-(
  32. But I remember that it reported something like 'ns_abstimeout table overflow'
  33. as the cause of the panic (this was the 3.0 host). I think it is also
  34. interesting that it said 'NFS server ruble ok' (the 2.1 host), immediately
  35. after the 'Killing all processes' message - looks to me like some sort of
  36. deadlock which can only be broken by killing the right process.
  37.  
  38.     Rainer
  39. --
  40. Rainer Staringer                   | rainer@fml.tuwien.ac.at
  41. Financial Markets Lab, TU Vienna   | +43 (1) 58801/8138
  42.