Path: utzoo!utgpu!watmath!clyde!att!rutgers!mit-eddie!uw-beaver!rice!sun-spots-request From: dupuy@columbia.edu (Alexander Dupuy) Newsgroups: comp.sys.sun Subject: Re: Shutting down a Sun System with a Shell Script Message-ID: <8811222300.AA12286@douglass.cs.columbia.edu> Date: 4 Dec 88 01:23:35 GMT References: <8811102135.AA09427@rice.edu> Sender: usenet@rice.edu Organization: Rice University, Houston, Texas Lines: 51 Approved: Sun-Spots@rice.edu Original-Date: Tue, 22 Nov 88 18:00:08 EST X-Sun-Spots-Digest: Volume 7, Issue 36, message 10 of 12 STELLABO@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@rice.edu". --wnl ]]