haltsys/reboot vrs. shutdown (was Re: init's untimely death.)

Ed Hew edhew at egvideo.UUCP
Thu Jun 29 14:00:00 AEST 1989


In article <132 at tridom.uucp> you write:
>In article <2045 at egvideo.UUCP>, edhew at 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 at egvideo.uucp}
>-------------------------------------------------------------------
>Warren Tucker, Tridom Corporation       ...!gatech!emory!tridom!wht 

  Ed. A. Hew     Authorized SCO Technical Trainer      Xeni/Con Corporation
  work:  edhew at xenicon.uucp	 -or-	 ..!{uunet!}utai!lsuc!xenicon!edhew
  home:	 edhew at egvideo.uucp	 -or-	   ..!{uunet!}watmath!egvideo!edhew
  # I haven't lost my mind, it's backed up on floppy around here somewhere!



More information about the Comp.unix.xenix mailing list