home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / fj / maillis / xwindow / 17581 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  4.2 KB
  1. Path: sparky!uunet!stanford.edu!sun-barr!sh.wide!wnoc-tyo-news!scslwide!wsgw!wsservra!daemon
  2. From: irvin@buffett.nas.nasa.gov (Timothy B. Irvin)
  3. Newsgroups: fj.mail-lists.x-window
  4. Subject: Keeping X going after fileserver system crash??
  5. Message-ID: <1992Nov18.091449.5658@sm.sony.co.jp>
  6. Date: 18 Nov 92 09:14:49 GMT
  7. Sender: daemon@sm.sony.co.jp (The devil himself)
  8. Distribution: fj
  9. Organization: NAS Facility, NASA Ames Research Center, Moffett Field, CA
  10. Lines: 82
  11. Approved: michael@sm.sony.co.jp
  12.  
  13. Date: Tue, 10 Nov 92 18:11:18 GMT
  14. Message-Id: <1992Nov10.181118.5523@nas.nasa.gov>
  15. Newsgroups: comp.windows.x
  16. Sender: xpert-request@expo.lcs.mit.edu
  17.  
  18. We maintain all the X stuff for our Sun SPARCs on a few replicated fileservers.
  19. We are beginning to use Amd to mount the closest fileserver, and to fall back
  20. to one of the replicated ones if the primary server fails.
  21.  
  22. The problem is, when X is running while the fileserver fails, X gets hosed and
  23. a reboot becomes necessary.  Even though a backup fileserver has been mounted.
  24. Which makes some sense, since the binary currently being run is still pointing
  25. to the primary fileserver.
  26.  
  27. So, we decided to move some of the X stuff to local disk, to see if most
  28. of X could survive lossing the fileserver.  I moved X, twm, and xterm to the
  29. local disk.  But with the dynamically linked libraries still on the fileserver
  30. this didn't buy us much.  So, I moved, libX11.so.4.3, libXaw.so.4.0, 
  31. libXmu.so.4.0, and libXt.so.4.0 to the local disk.  
  32.  
  33. Now X stays up.  Xterms are still usable, and all looked right with the
  34. world.  Until we tryed to start up a new X client (keep in mind that by now
  35. one the replicated fileservers had been mounted, so the new application
  36. was coming off there -- actually the problem occurred when running
  37. the client on another machine and displaying it on this machine).
  38.  
  39. After starting the new client, the server freezes for a few minutes.  Little
  40. to no mouse activity is possible.  After a few minutes the application
  41. finally arrives on the screen and the X returns to normal.  It appears
  42. to me that the X server has some file open on the first fileserver and
  43. has to go through an NFS timeout trying to read this file.  But we can't
  44. figure out what it would be, or how to get around it.
  45.  
  46. If the user exits out of X and restarts it, everything returns to normal.
  47. But we are trying to make a lost fileserver as seamless as possible (provided
  48. the limited amount of extra disk space we have each SPARCstation.
  49. Below is a segment of a trace of the xterm client starting up, the lines
  50. with *** in front are lines where activity froze waiting for a timeout.
  51.  
  52. Now the question:
  53. Does anyone know what file the server is trying to access, so we can move it
  54. to local disk (if not to big).  Or how to get the server to close this file and 
  55. reopen it (which would then use the replicated fileserver)?  Or any other
  56. suggestions which might help us out?
  57.  
  58. If possible please e-mail any suggestions: irvin@nas.nasa.gov. 
  59.  
  60. TRACE OUTPUT SEGMENT
  61. --------------------------------------------------------------------------------
  62.    writev (3, 0xf7ffdca8, 3) = 16
  63.    read (3, 0xf7ffdd20, 32) = -1 EWOULDBLOCK (Operation would block)
  64. ***select (4, 0xf7ffdbd8, 0, 0, 0) = 1
  65.    read (3, "".., 32) = 32
  66.    writev (3, 0xf7ffdca8, 3) = 20
  67.    read (3, 0xf7ffdd20, 32) = -1 EWOULDBLOCK (Operation would block)
  68. ***select (4, 0xf7ffdbd8, 0, 0, 0) = 1
  69.    read (3, "".., 32) = 32
  70.    brk (0x422e8) = 0
  71.    brk (0x432e8) = 0
  72.    writev (3, 0xf7ffd620, 3) = 72
  73.    read (3, 0xf7ffd698, 32) = -1 EWOULDBLOCK (Operation would block)
  74. ***select (4, 0xf7ffd550, 0, 0, 0) = 1
  75.    read (3, "".., 32) = 32
  76.    writev (3, 0xf7ffd620, 3) = 20
  77.    read (3, 0xf7ffd698, 32) = -1 EWOULDBLOCK (Operation would block)
  78. ***select (4, 0xf7ffd550, 0, 0, 0) = 1
  79.    read (3, "".., 32) = 32
  80.    write (3, "".., 352) = 352
  81.    read (3, 0xf7fff850, 32) = -1 EWOULDBLOCK (Operation would block)
  82. ***select (4, 0xf7fff708, 0, 0, 0) = 1
  83. ---------------------------------------------------------------------------------
  84.  
  85. PS  Each time it stoped on the "select" statements we'd get teh following in the
  86. console:  NFS getattr failed for server fs01: Timed out
  87.  
  88.  
  89. Thanks in advance,
  90.  
  91. Tim Irvin
  92. Systems Administrator (CSC)
  93. NASA Ames Research Center
  94. Moffett Field, CA
  95.