Path: utzoo!attcan!uunet!cs.utexas.edu!rutgers!att!ulysses!andante!alice!debra
From: debra@alice.UUCP (Paul De Bra)
Newsgroups: comp.unix.xenix
Subject: Re: haltsys/reboot vrs. shutdown (was Re: init's untimely death.)
Keywords: haltsys, reboot, shutdown
Message-ID: <9579@alice.UUCP>
Date: 7 Jul 89 18:55:57 GMT
References: <1989Jun21.114506.1378@tapa.uucp> <2045@egvideo.UUCP> <132@tridom.uucp> <2049@egvideo.UUCP> <3663@ddsw1.MCS.COM>
Reply-To: debra@alice.UUCP ()
Distribution: na
Organization: AT&T, Bell Labs
Lines: 29

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     |
------------------------------------------------------