home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / alt / hackers / 1861 < prev    next >
Encoding:
Text File  |  1993-01-06  |  4.6 KB  |  98 lines
  1. Newsgroups: alt.hackers
  2. Path: sparky!uunet!think.com!rpi!batcomputer!bouncer
  3. From: eirik@elf.TN.Cornell.EDU (Eirik Fuller)
  4. Subject: rebooting X terminals
  5. Message-ID: <1993Jan6.090609.28667@tc.cornell.edu>
  6. Sender: news@tc.cornell.edu
  7. Nntp-Posting-Host: earache.tc.cornell.edu
  8. Organization: Cornell Theory Center
  9. Date: Wed, 6 Jan 1993 09:06:09 GMT
  10. Approved: retired terminal
  11. Lines: 85
  12.  
  13.  
  14. I've got this Sun 3/50, you see; it used to be a terminal, but no
  15. more; now it's an ex-terminal ... oops, wrong newsgroup; this isn't
  16. alt.lame.humor ...
  17.  
  18. Sometimes, conditions on a file server require rebooting clients, not
  19. all of which have accessible consoles.  The reason might be a recently
  20. installed kernel patch, or migration to a different file server, or an
  21. ailing disk on the file server which necessitates moving client file
  22. systems to a healthier disk.
  23.  
  24. Most recently, the last of those reasons presented itself.  Coping
  25. with the usual diskless clients isn't hard; even becoming root in
  26. order to do so is facilitated by the writability, on the file server,
  27. of "/export/root/client/.rhosts".
  28.  
  29. Diskless X terminals present more of a challenge.  Rumor has it that
  30. some years ago, and some number of SunOS versions ago, four megs of
  31. 68020 memory would fit a windowing system on top of the usual daemons
  32. and such, without swamping the network with swapping traffic.  These
  33. days, however, with the version of SunOS (4.1.1) that was current when
  34. Sun3s officially became obsolete, a four meg sun3 is somewhat painful
  35. to use for its intended purpose, particularly with a window system
  36. that hasn't gone the way of Motorola CPUs and bundled C compilers.
  37.  
  38. However, a 4 meg 3/50 running nothing else except an X11R5 Xsun, with
  39. a command line that finds it an xdm to connect to, makes a pretty good
  40. monochrome X terminal.  Rebooting it with console access is trivial,
  41. but rebooting an X terminal that's locked into someone else's office
  42. presents a bit of a challenge.
  43.  
  44. I had already decided on a way of rebooting the ordinary Sun3 clients
  45. which, as it happened, worked out well.  What I didn't anticipate is
  46. that it worked wonders for the X terminals too.
  47.  
  48. The first thing I did was to rename /etc/bootparams and replace it
  49. with an empty file.  Next I rebooted the ordinary clients.  That
  50. allowed them to find their IP addresses via rarp, tftp the boot file,
  51. and sit and twiddle their thumbs while waiting for a bootparam server.
  52.  
  53. Next I unmounted /export/swap and /export on the file server, and used
  54. a dump|restore pipeline to copy /export to its new location.  I saw no
  55. need for such a pipeline for /export/swap; even with a sizable number
  56. of swap files, a Makefile that lists them all is easier, but in this
  57. case I did them by hand.  I remembered to exportfs everything in the
  58. new locations before allowing the clients to wake up.  I also did a
  59. level zero dump of the new /export while it was unmounted.
  60.  
  61. After I moved the original bootparams file back, the clients awoke
  62. from their bootparam slumber and returned to life.  What I wasn't
  63. expecting is that the X terminals did the same.  What happened,
  64. apparently, is that they freaked out when the swap partition was
  65. unmounted.  Ordinarily, when something like that happens, they'll come
  66. back up far enough to find the swap file still missing, spit blood,
  67. then sit and wait for someone to notice.  In this case, however, the
  68. empty bootparams file had the same effect I intended for the ordinary
  69. clients, of stalling the reboot until the new file systems were ready.
  70.  
  71. All this got me thinking about how to reboot individual X terminals,
  72. and I devised a way that seems to work pretty well.  It goes something
  73. like this:
  74.  
  75.     mv /etc/bootparams /etc/shoeparams
  76.     > /export/swap/exwife
  77.     telnet exwife 6000
  78.     # (watch /export/swap/exwife grow)
  79.     # (maybe even monitor the access time of /tftpboot/boot.sun3)
  80.     mkfile -n 8m /export/swap/exwife
  81.     mv /etc/shoeparams /etc/bootparams
  82.  
  83. That telnet command is there to goad the X terminal into noticing its
  84. inability to fit anything into its swap file, except for its
  85. consequent panic dump.  It might need a different port number if it's
  86. configured for a different display number.  It appears that ping is
  87. inadequate for this, along with telnet to port numbers for which it
  88. refuses connections (i.e. everything except its X socket).
  89.  
  90. While it would be simple enough to edit out just that client from the
  91. bootparams file, there's no harm in moving the whole thing out of the
  92. way, even for just one client.  In the unlikely case of another client
  93. wanting to reboot just then, there's no real harm in letting it wait
  94. for the return of the bootparams file.
  95.  
  96. Of course, this approach is complicated somewhat by a network with
  97. multiple bootparam servers, but the idea is pretty much the same.
  98.