home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / sys / sgi / 16260 < prev    next >
Encoding:
Text File  |  1992-11-10  |  2.1 KB  |  58 lines
  1. Newsgroups: comp.sys.sgi
  2. Path: sparky!uunet!news.tek.com!uw-beaver!news.u.washington.edu!news.uoregon.edu!cs.uoregon.edu!sgiblab!sgigate!odin!vesuvius.esd.sgi.com!betsy
  3. From: betsy@vesuvius.esd.sgi.com (Betsy Zeller)
  4. Subject: Re: Workspace doesn't start
  5. Message-ID: <1992Nov11.044402.10193@odin.corp.sgi.com>
  6. Keywords: workspace nfs nis
  7. Sender: news@odin.corp.sgi.com (Net News)
  8. Nntp-Posting-Host: vesuvius.esd.sgi.com
  9. Organization: Silicon Graphics, Inc.
  10. References:  <1992Nov10.111631.27264@uts.uni-c.dk>
  11. Date: Wed, 11 Nov 1992 04:44:02 GMT
  12. Lines: 44
  13.  
  14. In article <1992Nov10.111631.27264@uts.uni-c.dk>, carlkb@uts.uni-c.dk (Klaus Bock) writes:
  15. |> Some of our users cannot start workspace. It simply hangs as a process
  16. |> for ever, having used 0 cpu seconds. No display appears.
  17. |> 
  18. |> The users have home directories that are accessed via NFS. We don't run
  19. |> Yellow Pages (and we don't want to!).
  20. |> 
  21. |> However, for some users it IS possible to start workspace, even though
  22. |> their home directory is accessed via NFS.
  23. |> 
  24. |> We run 4.0.1 on the machine to start workspace, and 4.0.5 on the machine
  25. |> that exports the home directory of the users in question.
  26. |> 
  27. |> Does anyone know anything about this???
  28. |> 
  29. |> Regards,
  30. |> 
  31. |> Mogens Kjaer
  32. |> Carlsberg Laboratory, Dept. of chemistry
  33. |> Gl. Carlsberg Vej 10
  34. |> DK-2500 Valby
  35. |> Denmark
  36. |> carlkb@uts.uni-c.dk
  37.  
  38. The problem here is that Workspace checks to see whether there
  39. is a workspace process for that user on that machine, before it
  40. starts up. In 4.0.1, the mechanism that it used did not work
  41. well over NFS. A different mechanism was used in 4.0.5, and the
  42. problem will not occur on machines running that release.
  43.  
  44. To work around it, you can go to the users ~/.workspace directory,
  45. and remove the file called .wsLock<machinename>.0.0
  46. Instead, create a symbolic link in ~/.workspace/.wsLock<machinename>.0.0, and
  47. have it point to /usr/tmp/.wsLock<machinename>.<user>
  48.  
  49. eg ln -s  /usr/tmp/.wsLockvesuvius.betsy ~/.wsLockvesuvius.0.0
  50.  
  51. would do the job for user betsy on vesuvius
  52.  
  53. This should allow your users to run workspace. The problem
  54. is fixed in 4.0.5.
  55.  
  56. Betsy Zeller
  57. betsy@sgi.com
  58.