From: eirik@elf.TN.Cornell.EDU (Eirik Fuller)
Subject: rebooting X terminals
Organization: Cornell Theory Center
Date: Wed, 6 Jan 1993 09:06:09 GMT


I've got this Sun 3/50, you see; it used to be a terminal, but no
more; now it's an ex-terminal ... oops, wrong newsgroup; this isn't
alt.lame.humor ...

Sometimes, conditions on a file server require rebooting clients, not
all of which have accessible consoles.  The reason might be a recently
installed kernel patch, or migration to a different file server, or an
ailing disk on the file server which necessitates moving client file
systems to a healthier disk.

Most recently, the last of those reasons presented itself.  Coping
with the usual diskless clients isn't hard; even becoming root in
order to do so is facilitated by the writability, on the file server,
of "/export/root/client/.rhosts".

Diskless X terminals present more of a challenge.  Rumor has it that
some years ago, and some number of SunOS versions ago, four megs of
68020 memory would fit a windowing system on top of the usual daemons
and such, without swamping the network with swapping traffic.  These
days, however, with the version of SunOS (4.1.1) that was current when
Sun3s officially became obsolete, a four meg sun3 is somewhat painful
to use for its intended purpose, particularly with a window system
that hasn't gone the way of Motorola CPUs and bundled C compilers.

However, a 4 meg 3/50 running nothing else except an X11R5 Xsun, with
a command line that finds it an xdm to connect to, makes a pretty good
monochrome X terminal.  Rebooting it with console access is trivial,
but rebooting an X terminal that's locked into someone else's office
presents a bit of a challenge.

I had already decided on a way of rebooting the ordinary Sun3 clients
which, as it happened, worked out well.  What I didn't anticipate is
that it worked wonders for the X terminals too.

The first thing I did was to rename /etc/bootparams and replace it
with an empty file.  Next I rebooted the ordinary clients.  That
allowed them to find their IP addresses via rarp, tftp the boot file,
and sit and twiddle their thumbs while waiting for a bootparam server.

Next I unmounted /export/swap and /export on the file server, and used
a dump|restore pipeline to copy /export to its new location.  I saw no
need for such a pipeline for /export/swap; even with a sizable number
of swap files, a Makefile that lists them all is easier, but in this
case I did them by hand.  I remembered to exportfs everything in the
new locations before allowing the clients to wake up.  I also did a
level zero dump of the new /export while it was unmounted.

After I moved the original bootparams file back, the clients awoke
from their bootparam slumber and returned to life.  What I wasn't
expecting is that the X terminals did the same.  What happened,
apparently, is that they freaked out when the swap partition was
unmounted.  Ordinarily, when something like that happens, they'll come
back up far enough to find the swap file still missing, spit blood,
then sit and wait for someone to notice.  In this case, however, the
empty bootparams file had the same effect I intended for the ordinary
clients, of stalling the reboot until the new file systems were ready.

All this got me thinking about how to reboot individual X terminals,
and I devised a way that seems to work pretty well.  It goes something
like this:

	mv /etc/bootparams /etc/shoeparams
	> /export/swap/exwife
	telnet exwife 6000
	# (watch /export/swap/exwife grow)
	# (maybe even monitor the access time of /tftpboot/boot.sun3)
	mkfile -n 8m /export/swap/exwife
	mv /etc/shoeparams /etc/bootparams

That telnet command is there to goad the X terminal into noticing its
inability to fit anything into its swap file, except for its
consequent panic dump.  It might need a different port number if it's
configured for a different display number.  It appears that ping is
inadequate for this, along with telnet to port numbers for which it
refuses connections (i.e. everything except its X socket).

While it would be simple enough to edit out just that client from the
bootparams file, there's no harm in moving the whole thing out of the
way, even for just one client.  In the unlikely case of another client
wanting to reboot just then, there's no real harm in letting it wait
for the return of the bootparams file.

Of course, this approach is complicated somewhat by a network with
multiple bootparam servers, but the idea is pretty much the same.
Newsgroups: alt.hackers