GNOME Bugzilla – Bug 116814
Splash screen doesn't disappear
Last modified: 2005-09-06 12:40:26 UTC
gnomesession-2.3.3.1 If i've something other than the standard session , p.e. starting gaim and/ or evolution then the gnome session slash screen disappears only after some minutes. In this time you cant logout. The splash screen is on top. If you turn off splash screen the bahavior is the same. My last running version was 2.3.3 (i think).
If you edit ~/.gnome2/session, and remove the entry for gnome-session, this problem goes away. It looks like gnome-session may be trying to spwan itself.
Removing entry doesn't help here
I think this commit should fix it: 2003-08-08 Mark McLoughlin <mark@skynet.ie> * main.c: (main): make sure SM_CLIENT_ID gets set to a dummy id so that smproxy doesn't think we need to be session managed. Should fix bug 118063.
Problem still exists under a fresh installed system with gnomesession-2.4.1 ! I'ven't a running version until today.
It happens in my GNOME 2.4 (gnome-session 2.4.1-2) also. Looking at my gnome2/session file I do not see gnome-session at all. I tried removing the entry for gnome-smproxy, but no luck.
Created attachment 24744 [details] [review] Patch to make splash screen disappear after all client started
The attachment actually just a dirty hack. I just disable the code that I think prevent splash_stop() from being called. Because I find out that gnome-session enter the code section only when all client has been started. Actually I don't really understand the code, I just try to fix it, and it work, that's all.
More details - I'm running gnome-session 2.4.2. The problem only appears when I add gkrellm as an application that runs as an additional one (Startup Programs tab). When I remove gkrellm, the splash screen disappears almost instantly. (this is after erasing every file/directory that starts with . in my home directory).
Is this possibly a bug in gkrellm then? Is it the same with later gnome-session and gkrellm releases?
Well, yeah, gkrellm probably isn't implementing session management support correctly and that causes the problem. We should still be more robust against these problems, though.
*** Bug 148662 has been marked as a duplicate of this bug. ***
*** Bug 147686 has been marked as a duplicate of this bug. ***
We should be a lot more robust :/ This is one of the most frequently reported bugs by Novell's internal GNOME users, for what it is worth, and vincent appears to have found at least a half-dozen dups here.
This bug is also a part of bug 145179.
And should be related to bug 91273 somehow...
*** Bug 91273 has been marked as a duplicate of this bug. ***
*** Bug 120921 has been marked as a duplicate of this bug. ***
Bug 120921 also have a (much longer) patch.
Due to Luis' comment and the sheer number of dups, I'm bumping up the priority. Also due to his comment, I'm setting the version to 2.7.x. /me wonders why he wasn't added to the cc list when bug 91273 was marked as a duplicate of this bug
Retitling for clarity.
See the patch in bug #147686; is this fix correct?
We have that patch in the Novell package for gnome-session, BTW. For reference, it is attachment #29570 [details].
I'm going to mark this bug with the 2.8.0 milestone; however, the fact that we've already put up with this bug through several releases anyway might meant that we should punt this until 2.8.x (with x >= 1).
Hmm, patch from bug #147686 doesn't fix the testcase I gave in bug 147686 :(
I was speaking of attachment #29570 [details], of course (sorry for the spam)
Frederic: Um, you didn't comment in bug 147686 at all; did you mean the testcase you gave in bug 120921?
Yeah, I mixed bug containing patch and bug containing testcase :) Let's rehash : Patch from bug 147686 doesn't fix testcase from bug 120921
I'm seeing this too with the latest 2.8.x stuff and I think it was caused by adding gaim to my session.
Kjartan you are more likely seeing this: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=135735
I also often get bug reports caused by gaim. There is also a broken session handling in gdesklets. I can confirm the patch from bug 147686 doesn't work, it even makes things worse by triggering the problem with some valid setups where the current code works.
Is anyone seeing this in 2.9.x? Is it caused by problems in gnome-session or by badly managed apps?
it's caused by apps with a broken session management afaik and still here with 2.9 (according to the ChangeLog there is almost no code change since 2.5)
Well, it is caused by poorly managed apps, but g-s-m's behavior in the face of poorly managed apps is terrible. (And yes, it is still in 2.9.) The timeout for the display of the splash screen should be much shorter.
I am currently working on an app (http://yarssr.sf.net) that causes this behavior. Is there anything in particular I should be looking for to fix it? Right now I am just calling Gnome2::Program->init when the program is started. Is there anything else that I should be worrying about?
*** Bug 169379 has been marked as a duplicate of this bug. ***
I have the same problem with my gnome 2.8. I've read the topic but I didn't understand how to fix that.
I have the same problem with Gnome 2.10 (of course it is mentioned in the release notes). My problem extends to logout as well. Th culprit in my case seems to be esd which is taking a long time to start up for some reason. If I disable the sound server there is no problem but the hang is still evident at log out (not sure whether that is an esd issue) IMHO gnome-session should not wait for apps that are not part of the default session.
*** Bug 303423 has been marked as a duplicate of this bug. ***
In practice, I think most cases of this problem were caused by gnome-smproxy. We've removed gnome-smproxy in GNOME 2.12. See: http://mail.gnome.org/archives/desktop-devel-list/2005-July/msg00527.html So, if anyone sees this issue, please do the following: - Remove ~/.gnome2/session, log back in and try and reproduce the bug - Once you've reproduced it, verify that gnome-smproxy isn't running - If its not running, log a new bug (maybe mention this bug number) and attach your ~/.gnome2/session I've filed a new bug (bug #315350) about how we should better handle non-XSMP aware in apps in the session. However, if a non-XSMP app appears in the session, then that is a bug in itself which needs to be fixed separately from bug #315350