Bug 79829

Do you have any apps open?

No.

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

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

Happened again on RHL 8.0. I logged in at a VT and ran 'killall kdeinit'. The logout at X immediately finished then.

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

> it takes about a minute

When I managed to logout, eventually, it took me over five minutes
to logout which took me quite by surprise.  I was already convinced
that nothing will happen.  I repeated that experiment twice in a row
with the same results.

BTW - this bug seems to be really quite different than bug 80968
and independent.  See more information there.

Can people report on results with gnome-session 2.1.90 and other new packages
from the latest beta?

I haven't seen this problem in a while.

With a clean install of phoebe2, this happened today to me ( tried logout
several times, it won't work ). I couldn't replicate it. Any more info I could
provide?

All I can think of is that it's related to which apps are running, or bugs in
those apps.

couldn't gnome-session simply kill the apps which don't respond in several
seconds? getting the logout dialog is more important than saving current session.

It could/is supposed to, there is probably something more complicated going on.

I have had this in Gnome a total of five times now ...
It generally happens when I log in and decided to log
out within somewhere around 30 - 60 seconds of
logging in. 
This is after It appears to have completely logged in.
(ie. the splash screen is gone, the desktop icons are
visible and the taskbar is drawn)
When this happens it will sit for about  2-3 minutes
before the logout prompt shows up...  You either wait
or do a CTRL-ALT-BCKSPCE.
I'm not sure ... maybe there is a process hanging or
something. 
Not sure if it'll work, but next time it happens I'm gonna try
to go to another virtual console .. login real quick and run
'top' ... maybe I can see if a process vanishes from the list??
Just a thought..
   

FROM ISSUE TRACKER 13277 -- severity 4
this still happens with beta 4.

Larry: does issue tracker reporter give some reliable way to reproduce the 
problem? Please ask them how they are testing.

Possible clue: http://bugzilla.gnome.org/show_bug.cgi?id=105338

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

Havoc, any info we could provide when it happens which might help debugging this?

About being related to the apps running, when I logout I usually have open the
apps which are started by gnome session, no other strange programs. When the
logout didn't worked I closed all of them, but it still didn't work (
gnome-panel and applets still running though ).

I think I'm just going to have to debug it; hopefully I can get the problem to
happen, if I can, I should be able to debug it OK. If not, it'll be hard to figure
out a fix.

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

In simple attempts (log in, log out) I'm not seeing this happen, unfortunately.
No one has any reliable way to reproduce?

There is a "GSM_VERBOSE_DEBUG" env variable that can be set prior to running
gnome-session, perhaps add "GSM_VERBOSE_DEBUG=1 exec gnome-session" to 
.Xclients, chmod +x .Xclients, then log in as session "Default"
I'm not sure the verbose mode is that helpful but perhaps it would be.

Created attachment 90085 [details]
messages before logout screen appears

Created attachment 90086 [details]
messages after logout

I think I should add that I use redhat 8.0, not rawhide or phoebe. but it looks
like the same bug, so I hope the files are helpful...

NOTE FROM HP....
fixed in gingin prebeta5.
CLOSED ISSUE TRACKER 13277.

hp: This is fixed? If so we should close this bug.

I do not see this as originally reported.

I do see that logout "hangs" (not the confirmation) for a long time (usually
longer than I want to wait and I alt-ctl-backspace).  This happens when I have
been logged on for a long time.  If I login, wait for all applications etc to
start and then logout, it works fine.

SHould I put this in as another (different) report.  This occurs on 8.0.94.

I don't really know if it's fixed, as I've never been able to reproduce it anyhow.
#84291 was just one theory I had.

Hmm. I have seen this before, but not after upgrading gnome-panel and
gnome-applets. So it might indeed be fixed.

Let's assume fixed pending reports otherwise.

We have now reproduced slow logout as follows:

 - start xmms
 - log out saving session 
 - log in
 - "gnome-session-save --gui" or log out

If other people were or were not running xmms that would be helpful 
confirmation. Investigating the issue now. (xmms wasn't necessarily 
running, but if you had it in your ~/.gnome2/session maybe that would 
be enough)

I am running xmms all the time and noticed this bug

I reproduced this again. And that machine never ran xmms.

i've been seeing the same problem and if i bail out quickly with
ctrl-alt-backspace, there will be a vestigial /usr/libexec/gconfd-2 process left
over that will stick around for a few minutes and then go away.  looks like this
is the culprit that's clogging the works when trying to log out. 

No, gconfd isn't related to logout; it's not connected to the session manager or
the login session in any way, that's why it persists. It simply exits 2 minutes
after all applications a user is running anywhere stop using it. So if 
all your apps exit gconfd will exit shortly thereafter. But if you're logged 
in twice, you have to log out of both sessions before gconfd will exit.

I reproduce the logout problem in the following way. I have standard Redhat
Linux 8.0 (with applied erradata from Redhat).
I login from gdm. Everything starts nicely. When everything has started I try to
logout (that is logout is the first thing I do). No logout dialog appears for a
while. If I start the control-center (from the menu Preferences | Control
center) the logout dialog appears immediately. I agree that it was waiting for
something. If I cancel, the behaviour of logout is restored to normal.
I hope this helps.

I just want to add that I can "wake" the logout dialog not only with the control
center but with most items of the preferences menu, and other non-gnome
applications (like for example the tora database tool based on Qt).
I find that very confusing...

I've found a way to reproduce the bug: I only have to add some app to the
"Additional startup programs", then I logout.

login

immediately logout 
-> stalled

I can make the logout screen appear immediately by selecting an item in the
preferences menu, as someone else has said before.

but: I've encountered the bug before I've tried adding programs to the
additional startup programs, so there apparently are other possibities to
trigger the bug...

but maybe the bug has something to do with saving the session when non-gnome
apps are running?

ok, immediately after having written the last entry, I tried out the other
"variant" of this bug:

having xmms running and saving the session

after the next login I again had to wait for the logout. but the "preferences"
menu trick didn't work then.

I closed xmms.

still no logout

then I looked into the running programs in "current session" - and xmms was
still there! removed xmms from the session, pressed apply -> the logout screen
appeared

I'm going to try to find other apps that cause this behaviour. 

I have the same problem and it was caused by fooling around with my startup
applications.  Did anyone ever find a way to fix this problem?  It is really a drag.

The generic fix is probably to shorten the timeout, but at some point it's short
enough that apps could be killed instead of saved when they were legitimately 
still busy saving.

Another option might be to provide some kind of progress indicator for which 
app is being saved currently so you can know which app to blame.

Anyhow, short of those things it's just a matter of fixing specific apps.

in my experience, this bug only shows up when you try to save a session
consisting of apps that metacity recognizes as not session management aware, but
that are in spite of that restarted on the next login. examples seem to be xmms,
gkrellm.

or if you add startup applications.

the fix can't be "make all apps session management aware", can it?

If they aren't SM-aware at all the session manager should (and I think does) 
ignore them so there's no problem. The problem is something like xmms was:
session aware but _broken_. I fixed xmms. I don't know how many other apps 
out there try to do SM but fail.

If you add something as a "startup program" I wonder if the session manager does 
something really silly and just adds the app as if it were session aware, 
if so that would break.

Closing some bugs that have been in MODIFIED for a while. Please reopen if the
problem persists.

I have found another app that makes "logout take ages to work". it's gkrellm. on
severn.