I'm not exactly sure what you mean. Does this mean clicking on the
logout button on the panel does nothing, or that when the logout
dialog appears and you click OK, nothing happens ?

In either case, though, I can't see how the session file would cause this.

I mean that pressing the logout button has no effect. Maybe the
session file has nothing to do with it. The fact is that when this
first happened I tried a few times to manually kill gnome-session,
then to log back in, and still the same problem happened. I tried
rebooting as well, which didn't help. Only when I deleted my session
file the logout worked again.
Maybe it's a random coincidence. I'll try to reconstruct it. More to
come..

Yeah, any more info you can give around whether the session file is
actually casing this would be a great file. I know it its a pain
having to log out to try out this stuff.

Also. Call me stupid, but I can't to be sure which "logout button"
you're talking about

a) logout button on the panel
b) logout button in the logout dialog

Thanks

'Logout' button on the panel.
I still haven't checked about the relevance of the session file.

I was able to get this same behavior today when trying to duplicate
bug #91273.  I put my comments in that bug, so look there for what I
did.  Also, as I mentioned there, this unresponsiveness of the 'Log
Out' on the panel seems to only occur for a limited time which
explains why this bug probably wasn't spotted sooner.  So, this may be
a duplicate of bug 91273, though they are definitely written about
different observed behaviors.

I'm going to reopen this and add myself to the cc list.  I'm also
adding GNOMEVER2.0 and bugsquad keywords and setting Version to 2.0.x.
 I'm not sure where the priority and severity should be, so I'm just
going to set them to High and Major to make them match bug 91273.

Oops, I forgot to mark this as new.  Doing that now.

I am seeing this behavior in a recent CVS build as well.  On my
machine, GNOME has to be up for about 2 minutes before Log Out will
respond.  If I boot and immediately hit Actions->Log Out, nothing
happens.  About 2 minutes later, the Log Out window pops up (without
me choosing Actions->Log Out again).  After that time, Log Out
responds immediately.

This also appears to be reported in bug 106454 (filed against gdm). 
Note that I do not run gdm.  This should probably have the GNOMEVER2.3
keyword as it is still present in CVS HEAD (I can't add it).

Thanks for the update.  I just changed the version to 2.3.x (CVS HEAD
wasn't a listed option) and changed the keyword GNOMEVER2.0 to
GNOMEVER2.3.  I also added a comment to bug 106454--I think it's a
duplicate of this bug, but I'm not totally sure so I'm going to let
someone else mark it.

I looked through the code and I think I have a pretty good idea why
this is happening, but I'm not sure how to fix it (I looked at this
code for the first time today, so this may be wrong).

In gnome-session/manager.c, there is a start_list that contains the
processes to be started when GNOME starts.  These entries are popped
off the list and passed to start_client, which starts them and puts
them on the pending_list until they are registered.  They are given a
timeout (purge_delay, which defaults to 2 minutes) via gtk_timeout_add
to register themselves before being moved to a purge list.  The
register callback is added in new_client, which I assume is a callback
from ICE.  On my machine, gnome-smproxy, metacity, gnome-panel, and
nautilus all get passed into new_client and are thus registered
properly.  However, my applets do not.  Since they do not register,
they stay on the pending_list, so the save_state stays set to
STARTING_SESSION.  This is the state of the system when I press
Actions -> Log Out.  Since the save_state is not MANAGER_IDLE, when
the request comes through save_yourself_request, it gets queued on the
save_request_list.  It stays on that list until the applets get purge
called on them, which then calls update_save_state.  purge removes
them from the pending list, and update_save_state changes the
save_state to MANAGER_IDLE when the pending_list empties.  Once this
happens, update_save_state notices the outstanding request on
save_request_list and pops up the Log Out box (this is why I only had
to press Log Out once and it was honored 2 minutes later).

I have confirmed this by changing the purge_delay, which changes how
long I have to wait, and by processing the save request immediately in
save_yourself_request despite the save_state being set to
STARTING_SESSION.  The latter approach allowed me to log out
immediately, but it's not really a solution as I shouldn't log out if
the session is really still starting.

The best solution would probably be if new_client was called for the
applets and they were properly registered.  But that seems to be a
callback associate with X, so I have no idea why it's not triggering
for the applets.  Any ideas?

Ah, okay. I see. The applets had previously been saved into the
session file but they don't support session management anymore. So
when you go to log out, the session manager waits for them to respond
until the purge delay is up .. but of course they never do respond.

The quick workaround for that is to remove the applets from the
session file. They should never have been there.

But, this behaviour is clearly wrong and needs to be fixed - i.e. the
behaviour that things get stuck if we have non-session managed clients
in the session file.


One thing, though. Does this only happen if you go to log out straight
after logging in ... or does it always happen ?

I would expect the non-repsonding clients to get purged two minutes
after the session managers starts and for the session manager to go to
idle then.

Maybe its that they are not getting purged properly and that when you
go to log out the session manager sends them a SaveYourself even
though it shouldn't ?

It only happens if I attempt to log out immediately after logging in
(or at least before purge_delay is up).  After purge_delay is up, they
do get purged and the save_state goes back to IDLE, so log out works
correctly after that point.

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

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

Mark, is this still a problem?

BTW this has not happened to me ever since I switched to 2.4.x series.

Thomas, is this still relevant? At any rate, given that it only happens if you
try to log out in the first two minutes of the session, I'm moving it down.

I haven't been able to recreate it for quite some time (probably since switching
to 2.4.x).  I don't know if it is fixed or if I just failed to recreate it though.

Okay, sounds like this has fixed itself. Go gnome-session ! :/