Description of problem: It happens from time to time that logging out of a gnome-session leaves behind various clients still running. Apparently the condition can be recognized that it takes a really long time to logout. If this happened then when you will try to log the next time on an affected account you will get an alert: "I've detected a panel already running and will now exit." with only "OK" button to hit. Picking up that button will only open the next alert of the same sort and so on in an infinite loop. It appears that now you are basically screwed because even getting on a console and killing that stuck gnome-panel process is not of much help. You may get a new gnome-panel, or start it, but it may come totally blank, or with some other/extra entries it was originally configured, and in any case it does not respond to mouse clicks so even a clean logout is impossible. So far it appears that a full recovery from this condition may require a full reconfiguration of the whole desktop from scratch although a reboot may save some work. Processes in question show up in 'ps' output in "Ssl" state (this is always the case for such "left behind" gnome-panel) or "Ss" or "Sl". This is a list after one such incidents on a non-root account ('pgrep -u <user>' output so a number of columns is limited): 3522 gam_server 3669 bonobo-activati 3684 gnome-panel 3687 gnome-vfs-daemo 3746 mixer_applet2 3790 esd and, with a possible exception of gam_server, they should be, AFICS, gone. If you will catch up that something like that happened and do 'pkill -u <user>' (or more delicate if this happened to root) _before_ trying to start a gnome-session the next time then things are sane until the next incident. Version-Release number of selected component (if applicable): gnome-session-2.13.91-1 How reproducible: hits apparently at random
I had this too, but fortunatly no longer have it (the hanging at end of session and many processes including panel staying around). But session managment still is pretty much hosed: Menu->System->Preferences->More Preferences->Sessions has serious issues: -it contains a ask on logout checkbox, which does not seem todo anything -it contains an automaticly save session on logout checkbox, but it seems to (almost) never save my settings. -I can add all programs I want add the "Startup Programs" tab, but the next login they wont start and the list is back as it was. -Trying to delete a app from the Startup Programs" tab causes the dialog to hang and use 100% cpu. Also but this is already reported in wromgly imported the "Startup Programs" list from my old gnome settings.
> I had this too, but fortunatly no longer have it Maybe this happens with a somewhat decreesed frequency but I am seeing that quite regularly on a system updated to everything current in this moment. Just on a the last logout from a seesion everything was sitting doing apparently nothing for a while and surely enough 'pgrep -l -f gnome' reports: 2574 gnome-panel --sm-client-id default2 2584 /usr/libexec/gnome-vfs-daemon --oaf-activate-iid=OAFIID:GNOME_VFS_Daemon_Factory --oaf-ior-fd=31 and all other session clients, like described originally, are there too. Killing 'mixer_applet2' process makes all of them to go away with an exception of 'gam_server'. This seems to be consistent (although I have no idea how to recreate the whole thing "on demand"; after a few tries usually it happens).
if you add AlwaysRestartServer=true to the [daemon] section of /etc/gdm/custom.conf does it work around the problem for you?
I will try this "AlwaysRestartServer=true" but I doubt if this will help. The reason is that after I had these clients stuck I tried 'pkill -f gdm'. This restarts gdm afresh but these straggler were still there.
Re comment #3: AlwaysRestartServer=true did not help at all. I got a hit on the first try. Lucky me! gdm server did restart after a logout but after _that_ I am seeing 2068 with 'pgrep -u $USER -f mixer_applet2' and all other unwanted stragglers, including gnome-panel, are still there. As a nasty workaround I see a possibility of putting into PreFetchProgram something which does 'pkill -f mixer_applet2' but this will be really vile if there are multiple desktops, possibly with various users, running on such machine. BTW - this is a standard situation in my household. I do not see how 'pkill -u $USER -f mixer_applet2' may help as $USER will be 'root' at that moment (and even if this would work then multiple desktops owned by the same user are still out). Any better ideas beyond making sure that the real bug is fixed? This is something which showed up only recently. Besides logging out in such state really takes a while.
Re-checking all what learned about this the real culprit is mixer_applet2. Where is the bug I do not know. This depends on what is really responsible for an after session cleanup and if proper protocols are observed.
So if you remove the mixer applet from your panel, does the problem go away?
Removing "Volume Control" from a panel indeed seems to help. At least I was not able to reproduce the problem with few tries and it should otherwise hit by now. 'AlwaysRestartServer' was turned off in a configuration (and it does not seem to be relevant anyway). There is a catch. Removing this applet from a panel turns out to be quite difficult exercise. See bug #184285. I also cannot tell if some other applet will not cause similar difficulties.
I think that resolution to bug #184285 provides a fix to this problem as well. Any opinions to the contrary?
No, this should be fixed indeed.
What about my other session problems, shall I file a new bug? : Menu->System->Preferences->More Preferences->Sessions has serious issues: -it contains a ask on logout checkbox, which does not seem todo anything -it contains an automaticly save session on logout checkbox, but it seems to (almost) never save my settings. -I can add all programs I want add the "Startup Programs" tab, but the next login they wont start and the list is back as it was. -Trying to delete a app from the Startup Programs" tab causes the dialog to hang and use 100% cpu.