home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / sun / admin / 9556 < prev    next >
Encoding:
Internet Message Format  |  1992-12-17  |  1.9 KB

  1. Path: sparky!uunet!olivea!spool.mu.edu!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!sun-barr!male.EBay.Sun.COM!news2me.EBay.Sun.COM!exodus.Eng.Sun.COM!jetsun.Eng.Sun.COM!robinson
  2. From: robinson@jetsun.Eng.Sun.COM (David Robinson)
  3. Newsgroups: comp.sys.sun.admin
  4. Subject: Re: SAVE ME FROM RPC.LOCKD
  5. Keywords: rpc.lockd
  6. Message-ID: <lj1j4vINNfoh@exodus.Eng.Sun.COM>
  7. Date: 17 Dec 92 18:53:19 GMT
  8. References: <1992Dec8.011935.25011@ibx.com> <1992Dec17.112649.6211@ucc.su.OZ.AU>
  9. Organization: Sun Microsystems, Mountain View, CA  USA
  10. Lines: 32
  11. NNTP-Posting-Host: jetsun
  12.  
  13. In article <1992Dec17.112649.6211@ucc.su.OZ.AU> matth@extro.ucc.su.OZ.AU (Matthew Hannigan) writes:
  14. >In article <1992Dec8.011935.25011@ibx.com>
  15. >     steve@ibx.com (Steve Giuliano) writes:
  16. >>I've got several 6x0 machines that sit all day and bitch about
  17. >>
  18. >>    rpc.lockd: cannot contact status monitor!
  19. >>
  20. >>Meanwhile it usurps about 25% of my CPU.  Yes rpc.statd is running.
  21. >>BTW, portmap is screaming during this time too.
  22. >
  23. >rm /etc/sm/* /etc/sm.bak/* worked for me when I got this problem.
  24. >
  25. >Don't _really_ know why :-) but see the manual for statd.
  26.  
  27. The locking protocol depends heavily on the status monitor protocol.
  28. When a lock is requested by a client it first contacts the local status
  29. monitor to have it "monitor" the server.  When a host is monitored
  30. an entry is placed in the /etc/sm directory.  The server likewise
  31. monitors the client.  If one or the other crashes the status monitor
  32. upon reboot uses the stored files as a list of hosts to contact and
  33. inform them that they have rebooted and to either free or rerequest their
  34. locks.
  35.  
  36. Now situations occur where the status monitor can't contact another
  37. host (permenantly dead) and it will dilligently keep trying to contact
  38. the other host.  Removing the /etc/sm and /etc/sm.bak files essentially
  39. erases the host's long term memory so it will keep retrying
  40. other hosts on reboot.  
  41.  
  42. Combine this with bugs in lockd and you get your problem.
  43.  
  44.     -David
  45.