edhew@egvideo.UUCP (Ed Hew) (06/29/89)
In article <132@tridom.uucp> you write: >In article <2045@egvideo.UUCP>, edhew@egvideo.UUCP (Ed Hew) writes: >> >> RTFM says something like: "shutdown can only be run in the foreground by >> root". > >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. [we were talking about what happens when init dies and your process table fills up.....] The only problem (if you recall the context of the discussion), is that you can only do this if you are still able to log in *somewhere*, and have an available slot in the process table to run *just_one_more*. 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. I'd greatly prefer to run shutdown. It does all the above. haltsys/reboot simply terminate the system. It's the same effect as using the "big red switch", with the exception that the power is still on. The one thing I don't really know is what it is exactly that haltsys does to terminate the system. Anyone have any comments on how haltsys does it's job? --ed {edhew@egvideo.uucp} >------------------------------------------------------------------- >Warren Tucker, Tridom Corporation ...!gatech!emory!tridom!wht Ed. A. Hew Authorized SCO Technical Trainer Xeni/Con Corporation work: edhew@xenicon.uucp -or- ..!{uunet!}utai!lsuc!xenicon!edhew home: edhew@egvideo.uucp -or- ..!{uunet!}watmath!egvideo!edhew # I haven't lost my mind, it's backed up on floppy around here somewhere!
jbayer@ispi.UUCP (Jonathan Bayer) (07/01/89)
In article <2049@egvideo.UUCP> edhew@egvideo.UUCP (Ed Hew) writes: >In article <132@tridom.uucp> you write: >I'd greatly prefer to run shutdown. It does all the above. haltsys/reboot >simply terminate the system. It's the same effect as using the "big red >switch", with the exception that the power is still on. The one thing I >don't really know is what it is exactly that haltsys does to terminate the >system. Anyone have any comments on how haltsys does it's job? Haltsys _does_ do a clean shutdown of the system. Shutdown does several things. It will wait a period of time, send messages to all the users, send various kill commands to all the running processes to notify them that the system is going down, do hard kills on the remaining processes, and finally it executes haltsys. Quoting from the SCO Manual: "The _haltyss_ utility performs a _uadmin()_ system call to flush out pending disk I/O, mark the file systems clean, and halt the processor." JB -- Jonathan Bayer Beware: The light at the end of the Intelligent Software Products, Inc. tunnel may be an oncoming dragon 500 Oakwood Ave. ...uunet!ispi!root Roselle Park, NJ 07204 (201) 245-5922 jbayer@ispi.UUCP
karl@ddsw1.MCS.COM (Karl Denninger) (07/02/89)
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, <well-connected>!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"
davidsen@crdgw1.crd.ge.com (William E. Davidsen Jr) (07/04/89)
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. | 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... | | --ed {edhew@egvideo.uucp} | >------------------------------------------------------------------- | >Warren Tucker, Tridom Corporation ...!gatech!emory!tridom!wht | | Ed. A. Hew Authorized SCO Technical Trainer Xeni/Con Corporation 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
wht@tridom.uucp (Warren Tucker) (07/04/89)
In article <1090@crdgw1.crd.ge.com>, davidsen@crdgw1.crd.ge.com (William E. Davidsen Jr) writes: > I would not have posted this reply, or been so critical, but > this is a pile of (misinformation) to come from a technical trainer. And I certainly would not tell the networld to crash their systems! > - bill davidsen (davidsen@crdgw1.uucp) > GE Corp. R&D Center; Box 8, KW-C206; Schenectady NY 12345 -- ------------------------------------------------------------------- Warren Tucker, Tridom Corporation ...!gatech!emory!tridom!wht Sforzando (It., sfohr-tsahn'-doh). A direction to perform the tone or chord with special stress, or marked and sudden emphasis.
debra@alice.UUCP (Paul De Bra) (07/08/89)
In article <3663@ddsw1.MCS.COM> karl@ddsw1.MCS.COM (Karl Denninger) writes: >... >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. >... Beware! Though haltsys tries to sync the disks before halting the system it may fail to take care of processes that are still writing files while the sync is in process. (In the case of an almost locked up system this may not be a big problem.) I have tried and succeeded in combining running processes with haltsys to obtain a corrupted file system (which is marked as "clean" by haltsys). Running fsck on the filesys did reveal inconsistencies, but you won't notice this immediately if you don't perform fsck manually, cause the boot process will believe the file systems are clean. The heart of the problem is that haltsys does not kill the running processes *before* syncing the disk, and that the search for buffers to flush is not fail-safe. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------