dupuy@columbia.edu (Alexander Dupuy) (12/04/88)
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 ]]
frank@morgan.com (Frank Wortner) (12/04/88)
In article <8811102135.AA09427@rice.edu> Sun-Spots@Rice.edu writes:
)X-Sun-Spots-Digest: Volume 7, Issue 21, message 7 of 12
)
)Is there anyway to perform the following steps in a shell script from
)crontab on a Sun 3/280s file server:
One way to do it is to make an empty file (let's call it /.do-a-dump), and
then bring the system to single user. Root's .profile then checks for the
existence of /.do-a-dump. If it exists, the .profile runs the desired
program. A /etc/reboot brings everyone back to snuff.
I used to do incremental backups this way on Suns and an Alliant, so I'm
reasonably confident ;-) that it works.
--
Frankmagi%uwocsd.uwo.ca@cornellc.cit.cornell.edu (David Wiseman) (12/04/88)
In X-Sun-Spots-Digest: Volume 7, Issue 21, message 7 of 12
From: STELLABO@CSHLAB.BITNET
Fred J. Stellabotte asks questions about taking suns down to single user mode
to run backup.
I've been playing with this for a little while and I may have a way to do
it. First a note of caution: I haven't tried this yet but I cannot see
any reason why it won't work.
Build a procedure that replaces /etc/rc.boot with another shell script
(being careful not to lose rc.boot) and then forces a reboot. The
replacement rc.boot would do whatever you wanted then replace itself with
the original rc.boot and force a reboot again.
Has anyone out there tried this yet? Can anyone tell me why this is a
really stupid idea that should have been left in a wastebasket?
magi David Wiseman, Network Manager
Department of Computer Science
The University of Western Ontario
London Ontario Canada N6A 5B7joe@uunet.uu.net (Joe Michel-Angelo) (12/09/88)
STELLABO@CSHLAB.BITNET: > 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. The problem with this idea is the single->multi user bridge. As you see, it gets broken during the multi-single user transition. Don't know what you can do about that... unless you have the source for shutdown(8). You could always try a VERY buzzare method using file synchronization and the bsd-stuff-chars ability (ie: the ioctl call that puts chars into the clist). Someone once posted stuff.c to this news group. I can't recall the ioctl name. (Leaving for Dallas tonight!!!) Cron script would: using "stuff", stuff a login sequence into the console (if needed) after a root user is logged into the console, stuff "echo > /tmp/iamready" after /tmp/iamready exists, stuff "shutdown ... ; sleep 500 ; backup ... ; ^D" The script would die when the root/console user runs shutdown, but the sleep, backup, and re-enter multi user commands would be in a clist someplace just waiting to be executed. The above sequence won't work exactly as typed above. But the concept should work. You should know that it's never a good idea to have the root password sitting around! Personally, I'd not do this... too many problems would occure. Why not just backup /usr in multi-user mode? Perhaps tag /etc/nologin with a "Sorry -- backups being run" and then a nice wall message: "Hey, backups being run! Try not to edit anything!" ... Multi-user backups always work for me. Joe Angelo -- Senior Systems Engineer/Systems Manager at Teknekron Software Systems, Palo Alto 415-325-1025 joe@tss.com - uunet!tekbspa!joe - tekbspa!joe@uunet.uu.net
ado@ncifcrf.gov (Arthur David Olson) (12/09/88)
STELLABO@CSHLAB.BITNET writes: > Is there anyway to. . . > 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. . . No. A quick look reveals that. . . Script started on Wed Nov 23 17:19:42 1988 elsie$ /bin/ls -l /etc/umount /etc/dump lrwxrwxrwx 1 root 15 Oct 11 15:40 /etc/dump -> ../usr/etc/dump lrwxrwxrwx 1 root 17 Oct 11 15:40 /etc/umount -> ../usr/etc/umount elsie$ exit script done on Wed Nov 23 17:19:53 1988 . . .both /etc/umount and /etc/dump are "really" on the /usr partition. So when you try to umount /usr, the partition is "busy" and can't be unmounted; even if you *could* unmount it, you couldn't do the dump. To make things work right, Sun would at least get to move dump and umount to /sbin. Arthur David Olson ado@ncifcrf.gov ADO is a trademark of Ampex.
det@hawkmoon.mn.org (Derek E. Terveer) (12/12/88)
In article <8811102135.AA09427@rice.edu>, STELLABO@CSHLAB.BITNET writes: > Is there anyway to perform the following steps in a shell script from > crontab on a Sun 3/280s file server: > [steps described] > I have tried putting the above commands in a script and running the script > as super user with 'nohup' set, but my script is killed when the system > goes down to single user. I belive that one way of getting around this problem is to add an entry into your /etc/inittab file (if you have one -- i'm more of a sysV type...) that come into affect when going from init level 2 to level 1. Hope this helps, derek -- Derek Terveer det@hawkmoon.MN.ORG w(612)681-6986 h(612)688-0667
paula@june.cs.washington.edu (Paul Allen) (12/13/88)
stellabo@cshlab.BITNET writes: >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. How 'bout this? Modify your /etc/rc script so that just before going multiuser, a test is made for the existence of a flag file in /etc. Something like 'dumpflag'. If the file exists, it is removed and dumps are performed. Now, to initiate dumps, your script that is started from crontab merely creates the flag file and reboots the system with shutdown(8) or reboot(8). I experimented with a scheme like this a long time ago to the point that I was convinced it could work. I never put it into production, however, since it's so much easier to just do dumps in the middle of the night with the systems up and running. Haven't had any problems in a year of doing multi-user dumps. Note: If any wizards out there can poke holes in my suggested single-user-dump-from-crontab scheme, I'm all ears! Paul -- Paul L. Allen | paula@boeing.com Boeing Advanced Technology Center | ...!uw-beaver!ssc-vax!bcsaic!paula
steve@MATHS.WARWICK.AC.UK (Steve Rumsby) (12/17/88)
ado@ncifcrf.gov writes: > STELLABO@CSHLAB.BITNET writes: > > Is there anyway to. . . > > 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. . . > > No. A quick look reveals that. . . > Script started on Wed Nov 23 17:19:42 1988 > elsie$ /bin/ls -l /etc/umount /etc/dump > lrwxrwxrwx 1 root 15 Oct 11 15:40 /etc/dump -> ../usr/etc/dump > lrwxrwxrwx 1 root 17 Oct 11 15:40 /etc/umount -> ../usr/etc/umount > elsie$ exit > script done on Wed Nov 23 17:19:53 1988 > ... > To make things work right, Sun would at least get to move dump and umount > to /sbin. Yes, I didn't like the looks of this when I was installing 4.0. I mean, what happens if my /usr partition gets trashed? Install from the tapes and have to fix all the bugs and security holes again (1/2 :-). No thanks. Fortunately, due to the by now famous suninstall bug which causes it to crash on a serial console, and the fact that I didn't know about the fix, I ended up installing by hand. So when building my root file system I copied everything in sight from the munix root, which means I've got dump, restore, mount, umount, ls, mv, cp, etc, etc all on my root file system, along with all the relevant dynamic library stuff to make them work. A small trick is required though. Because /bin and half (or more?) of /etc are symbolic links into the /usr partition when it is mounted, I have /usr/bin, /usr/etc, /usr/lib directories in my root filesystem which get hidden when a working /usr is mounted. But if I don't have one, the symbolic links then point to the versions on the root filesystem instead and I can still do useful things. Of course my root filesystem is a bit (well, OK, a lot) bigger than normal, but that is a small price to pay. Steve. -- UUCP: ...!ukc!warwick!steve Internet: steve@maths.warwick.ac.uk JANET: steve@uk.ac.warwick.maths PHONE: +44 203 523523 x2657
exodus@decwrl.dec.com (Greg Onufer) (12/20/88)
elsie!ado@ncifcrf.gov (Arthur David Olson): > STELLABO@CSHLAB.BITNET writes: > No. A quick look reveals that. . . > Script started on Wed Nov 23 17: 19:42 1988 > elsie$ /bin/ls -l /etc/umount /etc/dump > lrwxrwxrwx 1 root 15 Oct 11 15: 40 /etc/dump -> ../usr/etc/dump > lrwxrwxrwx 1 root 17 Oct 11 15: 40 /etc/umount -> ../usr/etc/umount > To make things work right, Sun would at least get to move dump and umount > to /sbin. You are completely off-base on this one. You must be running SunOS 4.0. In SunOS 4.0 /usr is mounted read-only. So why bother going to single- user?? No one can change /usr (although some do... but that's just a sad story), so back it up whenever you want. But since all of us are not running SunOS 4.0, let me just say that I have never had a problem with full dumps done on active file systems. -greg -- Greg Onufer // Focus Semiconductor // University of the Pacific exodus@cheers.uucp (daver!cheers!exodus@Sun.COM) 415-965-0604
guy@uunet.uu.net (Guy Harris) (12/30/88)
>Yes, I didn't like the looks of this when I was installing 4.0. I mean, >what happens if my /usr partition gets trashed? Install from the tapes and >have to fix all the bugs and security holes again (1/2 :-). No thanks. Why not just bring up UNIX on the mini-root (following the installation steps up to the point at which you boot the mini-root) and use "newfs" and "restore" from the mini-root to restore "/usr" from dump tapes? As I remember, they're both on the mini-root. I thought that (modulo "mkfs" vs. "newfs" and "restor" vs. "restore") was Standard Operating Procedure all the way back to 4.1BSD (or whatever BSD release first introduced the mini-root). V7 had stand-alone versions of "mkfs" and "restor" that could be used for much the same purpose - the mini-root just obviated the need for quite so many stand-alone utilities.... [[ If /usr is on its own partition, you don't even have to mess with the "mini-root", just boot single user. In order to do this, however, you need to have made a dump of your /usr partition in the recent past. But you shoud be doing that periodically anyway. --wnl ]]