dirty restart problems ...

[William H. Magill]

On 09 Jun, 2004, at 13:59, Kevin Stevens wrote:
> ... Power cycle is the only way I know to resolve the situation.
> Followed by a reboot, BTW, as one REALLY, REALLY, BAD THING about
> OS X 10.3x is that the system will not come up reliably after a
> power cycle.  I don't mean unreliable as in fdisk gets stuck and
> you have to manually intervene, I mean unreliable as in it appears
> to come up properly, after an expected interval of "checking local
> disks", but is not in fact running critical services such as mail,
> DNS, or remote access (ssh).  You HAVE to do a normal reboot after
> a dirty start in order to ensure proper operation. This is a problem
> if you aren't physically at the box, because you can't log in remotely
> to do it.
>
> My assumption is that the rc dependencies aren't bulletproof, but 
> whatever
> the cause,it's a very, very bad thing.

I started another thread with this because it is a very different and 
important problem, which needs to be addressed.

In a word, I believe the answer to your assumption is "Yes!"

 From what I can tell the new concepts of the boot process are far from 
well thought out.

They only address the "optimal" situation -- where everything works "as 
expected."

I happen to have 10.2.8 running on my Beige G3 along with 12-9gig Ultra 
SCSI disks, and any time I have a crash or need to force a reboot 
without a clean shutdown, I have to do it twice. WHY? Because certain 
things which need to be running are not running, and things which 
depend upon them simply fail. (lookupd being the most notorious) and 
even though the system "comes up" and "looks ok" from the single user 
GUI (login window) point of view, it doesn't work correctly. [And yes, 
my G4 with the 160gig FW boot drive has the same problems, but 
differently.]

Granted, a portion of this is the way the daemons are written, but the 
reality is that some of the startup process "take time" before they are 
working, and part of the startup process expects everything to already 
be working correctly when it is "its turn" and no mechanism exists to 
hold those later parts until former complete. (Or if it does exist in 
the new boot scheme, it doesn't work correctly.)

If I remember correctly from my pokings around a while back, lookupd is 
the base culprit here. Given time, the pure unix stuff all works 
correctly, but anything which depends upon lookupd is screwed. It's not 
that lookupd is not running, it is, but it is giving out wrong 
information. One work-around is to change the look-up order to include 
flat-files. That way any of the pure unix apps will work "as expected" 
without lookupd getting in their face.

T.T.F.N.
William H. Magill
# Beige G3 - Rev A motherboard - 768 Meg
# Flat-panel iMac (2.1) 800MHz - Super Drive - 768 Meg
# PWS433a [Alpha 21164 Rev 7.2 (EV56)- 64 Meg]- Tru64 5.1a
# XP1000  [Alpha EV6]
magill at mcgillsociety.org
magill at acm.org
magill at mac.com