home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / sgi / admin / 312 < prev    next >
Encoding:
Internet Message Format  |  1993-01-28  |  2.2 KB
  1. Path: sparky!uunet!think.com!rpi!zaphod.mps.ohio-state.edu!caen!U.Chem.LSA.UMich.EDU!hillig
  2. From: hillig@U.Chem.LSA.UMich.EDU (Kurt Hillig)
  3. Newsgroups: comp.sys.sgi.admin
  4. Subject: rpc.lockd[167]: get_fd: unable to cvt fh: Stale NFS file handle
  5. Date: 26 Jan 1993 22:52:12 GMT
  6. Organization: Department of Chemistry, University of Michigan, Ann Arbor
  7. Lines: 42
  8. Distribution: world
  9. Message-ID: <1k4fasINN60u@srvr1.engin.umich.edu>
  10. NNTP-Posting-Host: u.chem.lsa.umich.edu
  11.  
  12. We've got a 4D/360 running Irix 4.0.5 as our main NFS server
  13. (among other things).
  14.  
  15. I've been getting the error messages:
  16.  
  17. Jan 26 17:32:51 Uranium rpc.lockd[167]: get_fd: unable to cvt fh: Stale NFS file handle
  18. Jan 26 17:33:51 Uranium last message repeated 29 times
  19.  
  20. etc., repeated roughly every two minutes for the past five
  21. days (in /usr/adm/syslog).
  22.  
  23. I interpret this to mean that somebody's trying to open/read/write
  24. a file which NFS thinks doesn't exist anymore, and is doing so
  25. very persistently.
  26.  
  27. I've checked every workstation that NFS-mounts filesystems from
  28. Uranium, done "umount -a" and then "mount -a" to try to flush things;
  29. likewise I've killed (well, in a friendly fashion...) every user
  30. process on every workstation which might have open files on the
  31. server; tried "exportfs -ua" / "exportfs -a" on the server; all to no
  32. avail.  I've rebooted the GatorBox which handles AppleShare-NFS
  33. translation for us, also with no effect.
  34.  
  35. I've played with netstat and nfsstat, both on the server and on those
  36. clients which support them, but haven't discovered anything useful.
  37. I just got a copy of EtherPeek for my Mac - of course with no
  38. documentation - but I don't see anything obvious in the traffic to/from
  39. the server (of course if I knew what to look for it might be more
  40. obvious...).
  41.  
  42. I'm about ready to reboot everything, but I'd like to know what's
  43. causing this first.
  44.  
  45. So, can anyone tell me how to determine which machine/process is
  46. causing this?  I'm setting up EtherPeek to capture traffic from
  47. 3 - 4 AM; what should i be looking for?
  48.  
  49. -- 
  50.       Kurt Hillig
  51.    Dept. of Chemistry      I always tell the     khillig@umich.edu
  52.  University of Michigan     absolute truth    Telephone (313)747-2867
  53. Ann Arbor, MI  48109-1055    as I see it.    hillig@chem.lsa.umich.edu
  54.