edhew@egvideo.UUCP (Ed Hew) (07/05/89)
In article <1090@crdgw1.crd.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >In article <2049@egvideo.UUCP> edhew@egvideo.UUCP (Ed Hew) writes: > >| 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. > > Hogwash! RTFM. They sync and mark the filesystems as clean. They >don't give the CPU back to the processes with a SIG to let them do >cleanup. There have been time when I really wanted to kill the system >without sync from software, haltsys doesn't do it, it's clean and >documented as such. I *should* have RTFM first, instead of relying on information I trusted to be accurate which I had previously received from other parties. [another good case for reading one's documentation at every opportunity, especially before posting!] As I don't have permission to reprint it verbatim, here's a summary of SCO's man page for haltsys as contained in the Xenix 2.3.1 manual, for those interested: - haltsys does a uuadmin() system call to flush pending disk i/o buffers, marks the filesystem clean, and halts the processor. - since haltsys takes effect immediately, user processes should be killed beforehand. (haltsys doesn't do this for you). - shutdown warns users, terminates processes and then calls haltsys, and is recommended for normal system shutdown, except in situations where it's impossible to run due to system problems. - haltsys locks hard disk heads. >| Odds are that you'll still have a bunch of temporary files sitting around, >| and any number of unflushed buffers. > > true and false, respectively. Of course any reasonable startup >will clean the temp files... > >| system. Anyone have any comments on how haltsys does it's job? > > It's all in the manual... > > I would not have posted this reply, or been so critical, but >this is a pile of (misinformation) to come from a technical trainer. >-- > - bill davidsen (davidsen@crdgw1.uucp) > GE Corp. R&D Center; Box 8, KW-C206; Schenectady NY 12345 Even technical trainers can be human. Since my original posting was issued in good faith, I have no problem posting this correction and the following summary in the same spirit. On Thu Jun 29 14:00:02 1989 I wrote: eh> [we were talking about what happens when init dies and your process table fills up.....] eh> The only problem (if you recall the context of the discussion), is that eh> you can only do this if you are still able to log in *somewhere*, and eh> have an available slot in the process table to run *just_one_more*. eh> eh> Even then, you probably will still have to run fsck to clean up, as neither eh> haltsys or reboot take you to single user mode, do any sync's, or cleanly eh> terminate all those processes that are spawned when you are multi-user. eh> Odds are that you'll still have a bunch of temporary files sitting around, eh> and any number of unflushed buffers. eh> eh> I'd greatly prefer to run shutdown. It does all the above. haltsys/reboot eh> simply terminate the system. It's the same effect as using the "big red eh> switch", with the exception that the power is still on. The one thing I eh> don't really know is what it is exactly that haltsys does to terminate the eh> system. Anyone have any comments on how haltsys does it's job? -- Since then, I have noted the following comments via both email and postings to comp.unix.xenix : -- DJ> From watmath!mailrus!ames!claris!portal!cup.portal.com!Dion_L_Johnson Sat Jul 1 02:34:51 1989 DJ> Date: Fri, 30 Jun 89 20:58:29 EDT DJ> Haltsys syncs the system too. I've never had any ill effects DJ> from using haltsys on 2.3.* XENIX. -- P> From watmath!uunet!ficc!peter Sat Jul 1 02:34:50 1989 P> We use something like this: P> P> ---- haltsync.c ---- P> main() P> { P> sync(); P> sleep(1); P> sync(); P> sleep(1); P> execl("/etc/haltsys", "haltsys", (char *)0); P> } --- JB> From: jbayer@ispi.UUCP (Jonathan Bayer) JB> Date: 2 Jul 89 04:00:00 GMT JB> Haltsys _does_ do a clean shutdown of the system. Shutdown does several JB> things. It will wait a period of time, send messages to all the users, JB> send various kill commands to all the running processes to notify them JB> that the system is going down, do hard kills on the remaining processes, JB> and finally it executes haltsys. JB> JB> Quoting from the SCO Manual: JB> JB> "The _haltyss_ utility performs a _uadmin()_ system call to flush out JB> pending disk I/O, mark the file systems clean, and halt the processor." JB> JB> JB -- KD> From: karl@ddsw1.MCS.COM (Karl Denninger) KD> Summary: Haltsys DOES update the disk before going down KD> Date: 3 Jul 89 04:00:00 GMT KD> Wrong! KD> KD> Try doing that "haltsys" right after copying a big file -- notice how long KD> it takes, and how your nice disk light is on for several seconds before the KD> system comes to a halt? KD> KD> Notice as well that your system doesn't fsck all the disk partitions on the KD> way back up -- because the "file system ok" flag is set! KD> KD> Haltsys is a clean shutdown. It doesn't terminate processes -- which means KD> that any programs that were running don't get the chance to get signalled KD> and quit cleanly -- but it DOES sync the disks, unmount them (effectively KD> though not though the "umount" system service), and take the system down KD> cleanly. KD> KD> I use this method all the time for shutdowns, and have never had a problem KD> with it. Then again, our system is set up to remove all the rogue lockfiles KD> and the contents of /tmp (AFTER "recover"ing for those caught in "vi") on KD> the way back up -- preventing problems with things like Usenet! -- Remembering the original reason for my posting, it's best to run shutdown if at all possible, failing which one can run haltsys or reboot as a last resort. This is still infinately preferable to simply turning off the power and crashing the system. Thanks to all who took the time to contribute to this discussion. Now, off to run _shutdown_ so that I can install some hardware in the box. --ed {edhew@egvideo.uucp}