+ does this still happen ?

 + if it does, does removing ~/.gnome2/session fix it?

removing ~/gnome2/session sort of helps.  When I removed it, gnome no
longer launches gkrellm on startup and instead begins just the way it
is supposed to.  When I add gkrellm back in, save my settings, and
then restart the problem comes back.

This is actually happening on 2 machines (forgive my memory, I sent
this bug in some time ago)  My home computer splash screen freezes
when loading gkrellm.  It works properly if I don't have gkrellm start
at login time but instead start it by hand after the splash has
disappeared.  (It would be awfully nice to have it launch automaticaly
though).  That splash screen will not go away and will not allow
anything to write on top of it until it times out and disappears on
it's own.

At work I have a fedora box with a very similar problem.  It too
lauches gkrellm on startup, but the splash screen blows by that and
instead hangs up much further down the list at
'evolution-alarm-notify'.  On that machine if I click on the splash
screen it goes away.

In either case the screens are not exiting the way they should be and
both appear to be waiting for a system call or application to load or
signal, and then give up after a timeout, or just finally get a really
really late signal.

Both computers were running RH9.0 before I upgraded them to FC1.  The
have both exibited their behavior since that upgrade.  Also, I have
moved my work PC to FC2 test 2, but that has had no bearing on the
splash screen start time.  I have several other PCs that started with
fresh installs of Fedora and do not show these problems.

It may also be worth noting that the gkrellm also automatically starts
in KDE but the KDE splash screen loads fine on either computer.

Thanks for looking into this.

bug #109510 says it's because of gaim being on startup.

*** Bug 109820 has been marked as a duplicate of this bug. ***

*** Bug 109510 has been marked as a duplicate of this bug. ***

Just from reading the report, my guess is that gnome-session is
treating gkrellm as a session-manager aware application and gets stuck
waiting for it to register itself.

What happens when you:

 1. create a file called ~/.Xclients with: 
       exec gnome-session --purge-delay 5000
 2. run chmod +x ~/.Xclients
 3. Login using the Default session

Does it still stall? Or rather does it stall for a significantly
shorter period of time? Incidentally, I think the default delay should
 probably be shortened anyway.

I created the .Xclients file just like you said and it reduced the
delay considerably!  The hangup at the gkrellm launch is now only a
matter of 5 or 10 seconds vs. the couple minutes it was before.  Thanks!

Is there any value I can change to shave just a little more time off
the startup?

The 5000 number there is the number of milliseconds to wait for the
programs being started to register with the session manager.   So if
you want it to wait less time, change the number to a smaller value. 
Beware , though, that if you make it too small then legitimate (but
slow) sm-aware programs will be rejected by the session manager.

This happens on a Kurumin I just installed gnome. It's not fedora-related.

*** Bug 103289 has been marked as a duplicate of this bug. ***

This issue is being tracked upstream.  Let's work on the problem there:

http://bugzilla.gnome.org/show_bug.cgi?id=148662