Shutting down a Sun System with a Shell Script

[Alexander Dupuy]

STELLABO at CSHLAB.BITNET (Fred J. Stellabotte) asks:
>Is there anyway to perform the following steps in a shell script from
>crontab on a Sun 3/280s file server:
>
>        1) Bring the system down to single user with the Shutdown Command
>        2) umount the /usr file systems
>        3) Perform a level (1-9) on the /usr file system
>        4) Re mount the file systems.
>        5) Bring the computer up in multi user.

When the system goes single user, all processes are killed, and a single
/bin/sh process running as root is started.  In order to do what you want,
you have to make that /bin/sh run your script, and then exit, causing init
to bring the system multi-user.  You could use /.profile, or under SunOS
X: X >= 3.2, you can use the file /etc/profile, which is sourced by
/bin/sh just before /.profile.

I actually do something a bit like this, except that I reboot the machine,
rather than just take it to single user, and run the script from /etc/rc,
as the machine is just starting to go multi-user.  But the same techniques
would apply in your case.  I prefer rebooting, since it can clear up
problems with immortal zombie processes, and/or other system glitches
which might not go away by just "changing the run-level" as they would say
in System V.  Since you're making the system unavailable to regular users
while you do the backup, there isn't really much difference.

I make this script available to operators to run interactively when they
take down a system for backups, but with the "-b" option, it can be run
from cron(8) (or even at(1), although I've had some problems with SunOS
3.x at).  It uses a modified version of script(1) which takes an extra
argument that specifies the program which should be run (instead of the
default interactive shell), and which has the parent (input) process wait
on the child process rather than exiting after it gets an end-of-file.

I can't provide the modified script(1) which my scheme uses, since it's
derived from the Berkeley/Sun sources.  You should be able to run this
without it, but you won't get the logfiles which I find terribly useful
for figuring out what went wrong with a backup (operators rarely remember
the exact error messages).  There's also a possibility dump will get
confused about the lack of a control terminal (/dev/tty), if that doesn't
get set up, but if there are no problems with the dump, everything will be
fine.  

Here's the script I use - you will have to modify it for your own configuration

[[ It is 16294 bytes:  far too large to include in a digest.  It has been
placed in the archives under "sun-source" as "fullbackup.shar".  It can be
retrieved via anonymous FTP from the host "titan.rice.edu" or via the
archive server.  For more information about the archive server, send a
mail message containing the word "help" to the address
"archive-server at rice.edu".  --wnl ]]