I have once tried to debug this in gnome-session (which is a pain for non-gnomerati) and found that somehow there was a dbus client in the inhibiters list. Unfortunately all the details (such as the originating process id) were empty, null or zero. I did find at the time, however, that this never happened on a re-launched X session (say after forced logout and re-login)
This made me think that it could be due to particularly fast boot. Is your system fast to boot up? Mine boots maverick in 5 to 6 seconds (on dual SSDs) There might even be something astray from the gnome-greater that is left hanging around in the desktop session. Another gnome issue on my box that is _definitely_ timing dependent is that my gdm greeter will hardly ever show all the user images. In fact it will usually display the first 2 (out of 4) but frequently none. I've similarly tried to debug that behaviour but haven't found a cause. The code is overly complex due to the dynamic zoom effects, yet the callback for the list box population is correctly called all the time. Apparently there is some early face condition on my fast system causing the user images to be unavailable. [1] What prompted me to write this up here was the fact that this bug has gone for a long time without any substantial clues so I reckon I'd just offer my humble 0.02$ Oh, perhaps other users affected by this bug can use d-feet to debug the state of dbus gnome session with the hung process. Seth [1] Sorry for the off topic rant. I will file a separate bug for this once. ----- Sent from a phone that is smart enough to allow me to successfully send SMS messages. -- You received this bug notification because you are a member of Ubuntu Desktop Bugs, which is a bug assignee. https://bugs.launchpad.net/bugs/313228 Title: a program is still running but i want shut down anyway -- desktop-bugs mailing list desktop-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
