Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!att!mcdchg!ddsw1!karl From: karl@ddsw1.MCS.COM (Karl Denninger) Newsgroups: comp.unix.xenix Subject: Re: haltsys/reboot vrs. shutdown (was Re: init's untimely death.) Summary: Haltsys DOES update the disk before going down Keywords: haltsys, reboot, shutdown Message-ID: <3663@ddsw1.MCS.COM> Date: 2 Jul 89 06:19:21 GMT References: <1989Jun21.114506.1378@tapa.uucp> <2045@egvideo.UUCP> <132@tridom.uucp> <2049@egvideo.UUCP> Reply-To: karl@ddsw1.MCS.COM (Karl Denninger) Distribution: na Organization: Macro Computer Solutions, Inc., Mundelein, IL Lines: 38 In article <2049@egvideo.UUCP> edhew@egvideo.UUCP (Ed Hew) writes: >In article <132@tridom.uucp> you write: >>haltsys or reboot is SCO's way of telling shutdown where to stuff it! >>It might not be nice for servers or off-hokk comm lines, but it WILL >>shut the system down RIGHT AWAY. > >You are correct in the above statement. ..... >Even then, you probably will still have to run fsck to clean up, as neither >haltsys or reboot take you to single user mode, do any sync's, or cleanly >terminate all those processes that are spawned when you are multi-user. >Odds are that you'll still have a bunch of temporary files sitting around, >and any number of unflushed buffers. Wrong! Try doing that "haltsys" right after copying a big file -- notice how long it takes, and how your nice disk light is on for several seconds before the system comes to a halt? Notice as well that your system doesn't fsck all the disk partitions on the way back up -- because the "file system ok" flag is set! Haltsys is a clean shutdown. It doesn't terminate processes -- which means that any programs that were running don't get the chance to get signalled and quit cleanly -- but it DOES sync the disks, unmount them (effectively though not though the "umount" system service), and take the system down cleanly. I use this method all the time for shutdowns, and have never had a problem with it. Then again, our system is set up to remove all the rogue lockfiles and the contents of /tmp (AFTER "recover"ing for those caught in "vi") on the way back up -- preventing problems with things like Usenet! -- Karl Denninger (karl@ddsw1.MCS.COM, !ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"