From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Description of problem: After upgrading from RH 9.0 to Fedora Core Test 3 my gnome login doesn't quite work right. When I login the splash screen comes up and starts all my applications, but it never closes. If I click on it after the desktop is loaded, then it closes, but if I don't it remains displayed indefinately. I am using a gnome desktop that was updraded by Fedora from the stock RH 9 distribution. Version-Release number of selected component (if applicable): gnome-desktop-2.4.0-1 How reproducible: Always Steps to Reproduce: 1.log in. 2. 3. Actual Results: Login occurs, but splash screen stops responding after starting Gkrellm Expected Results: The rest of the splash to display, then close. Additional info:
+ 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