[Ti] Lengthy Startup Time

[Chris Olson]

On Mar 16, 2005, at 12:05 PM, Kynan Shook wrote:

> That's not necessarily true - although it's possible that it's looking 
> for something on the network (and I've seen this happen), it's also 
> possible that it's beachballing because it can't read part of the disk 
> (and I've seen this happen too, quite a bit).  In fact, I would 
> consider this to be more likely.

I wouldn't consider that likely.  The data required to launch Finder is 
not contiguous on the disk, and a few bad blocks won't cause Finder not 
to launch.  If there's some bad blocks, those blocks get marked bad and 
the file system drivers move on and don't use them anymore.  If you ssh 
into the machine when Finder is trying to start you'll find Finder is 
already loaded into memory and hung, while lookupd is thrashing the 
living daylights out of your disk, querying NetInfo and your 
configuration stores.  Been there and fixed too many of 'em already.

I suggest perhaps referring to Apple's KB article on the subject:
http://docs.info.apple.com/article.html?artnum=300852

What Apple is failing to tell there is that they screwed up host 
lookups and the lookup daemon (lookupd - normally handled by "named" on 
other Unix systems) in 10.3.7.  10.3.8 is supposed to fix it, but it 
doesn't if you've ended up with a corrupted Finder cache or modified 
the hosts or NetInfo database to fix the issue in 10.3.7.  Removing 
networking capability so the machine halts host lookups is the way to 
verify it.  If lookupd cached the fact that a network volume can't be 
reached, even when it can, Finder will hang during start for 120 
seconds on each AFP or SMB lookup, waiting for it to time out.

If you suspect a disk problem, and realize that S.M.A.R.T. monitoring 
isn't perfect, boot the machine to single user and run fsck on the disk 
in interactive mode.  The Unix command line tool will tell you way more 
useful information about the status of your disk than the GUI will.
--
Chris