Unknown process not responding on shutdown

Bug #716167 reported by Aritchie on 2011-02-09
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
The Charlotte project
High
Alex Chiang
unity-2d
High
Bill Filler

Bug Description

This started happening right after I installed the unity-2d updates from 02-07-2011 and 02-08-2011. Every time now when I shut down I get this message box. I will let the screen shot explain. It always is identified as an Unknown process. This never happened before I installed the updates from the past two days as mentioned before. Of course when I click "shut down anyway" it does shut down the system. Update Manager did report when I did the update that is had to do a partial upgrade with the unity-2d launcher and did a distribution upgrade. Do you think this had something to do with it? I am just guessing - probably not. I wonder if I should remove unity-2d with Software Center and reintall it from a Terminal from within a Desktop Edition session or would that be a waste of time? Every thing else to work fine so far. Is there a shut down log that might give a better clue as to the process that refuses to end on a normal shut down? I am running this on Ubuntu 10.10 by the way.

Related branches

Aritchie (aritchie) wrote :
Aritchie (aritchie) wrote :

Hmm, well I tried an uninstall and then a reinstall, downloaded updates that Update Manager stated were available and it still does this.

Aritchie (aritchie) wrote :

Ok since I know the unity-2d launcher will run under a Desktop Edition session, I thought I would try it and then log out to see if I could reproduce the problem and sure enough it does. I started the launcher after logging into a Desktop Edition session and then logged out and sure enough; I got the exact same condition as in the screenshot I posted. The big difference it seems to me on the surface between this build and the one I had prior was the addition of the workspace switcher. Is there a configuration file I could edit and disable it temporarily to see if that is the problem or is that completely self-contained into the launcher?

Florian Boucault (fboucault) wrote :

That was a great idea you had Aritchie to try under the Desktop Edition session.

Let's try that again with a little more details. Can you try to log in the desktop edition session and start in a terminal:

$ unity-2d-launcher

Do nothing else, try to logout and report back here what you see.

Now try this other thing. Log in the desktop edition session and start in a terminal:

$ unity-2d-spread

Do nothing else, try to logout and report back here what you see.

Aritchie (aritchie) wrote :

Ok, here we go:

1. Logged into a Desktop Edition Session.
2. Started a Terminal session.
3. Typed "unity-2d-launcher".
4. Launcher started and on desktop.
5. I went to Logout.
6. Launcher goes away.
6. Message box appeared stated that an "Unknown Process - not responding".
7. This is the output in the Terminal window after the message box appeared:

(unity-2d-launcher:3375): GLib-GObject-WARNING **: invalid uninstantiatable type `(null)' in cast to `GObject'

(unity-2d-launcher:3375): GLib-GObject-CRITICAL **: g_object_get_data: assertion `G_IS_OBJECT (object)' failed

8. Clicked Cancel on the message box.
9. Typed "unity-2d-spread" in Terminal window.
10. I went to logout.
11. Same meesagebox appeared with same message as before Unknown Process not responding.
12. No additional output in Terminal Window - just blinking cursor.

This was installed on a fresh Ubuntu 10.10 Desktop Edition on a different system - so the unity-2d build was the latest from the repository.
That is all I observed gentlemen.

Aritchie (aritchie) wrote :

Ok I will have to change my comments about running unity-2d-spread. I should have realized that I should have clicked "Shut down anyway" and actually logged out. The message box that I thought was from unity-2-spread when I tried to log out was actually left over from unity-2d-launcher. I clicked "Shut down anyway",logged out and logged back into a Desktop Session and opened up a Terminal Window and started unity-2d-spread. I immediately went and logged out and no message box appeared stating there was an Unknown Process not responding and it logged me out just fine. So based on my test it looks like the issue is in the launcher. Unity-2d-spread does not seem to have an issue as far as I can tell.

ion ion (georgeionut999) wrote :

Same problem on Ubuntu 10.10 x64.

Aritchie (aritchie) wrote :

Oh I forget that little bit of info. I am running the 32-bit version of 10.10.

Eric Ch (eric-ch) wrote :

I have also the same problem with an Eeepc 1000HE and Ubuntu Netbook Edition 10.10 32 bits.
I get a message and a box with two unknown processes at computer shutdown. I must manually close theses processes and shutdown is achieved thereafter.

Changed in unity-2d:
status: New → Confirmed
importance: Undecided → Critical
milestone: none → 3.8
Changed in unity-2d:
importance: Critical → High
tags: added: charlotte-backport-needed
Florian Boucault (fboucault) wrote :

Similar to #706248

Bill Filler (bfiller) on 2011-03-09
Changed in unity-2d:
assignee: nobody → Bill Filler (bfiller)
status: Confirmed → In Progress
Bill Filler (bfiller) wrote :

This bug is related to bug #706248.
After much debugging, it seems the problem is related to how we are registering unity-2d-launcher and unity-2d-panel with gnome-session. We are registering with gnome-session such that these two application can be restarted automatically by the session when they crash.

The registration code is in libunity-2d-private/src/gnomesessionclient.cpp in method connectToSessionManager(). On logout, the method queryEndSession() is called. Note that endSession() and stop() methods NEVER get called which doesn't seem correct.

I was able to make the "Unknown process" dialog go away (at least couldn't make it fail in my testing) by changing the dbus call in queryEndSession() to async instead of sync,
i.e.
    QDBusPendingCall call = iface.asyncCall("EndSessionResponse", true, "");
instead of:
  QDBusReply<void> reply = iface.call("EndSessionResponse", /* is_okay= */ true, /* reason= */ "");

But even in changing call to async, the long delay still occurs on logout (bug 706248) so clearly we are still not doing something correctly. Commenting out the impl in connectToSessionManager() fixes both problems, but then launcher and panel won't restart on crash.

I'm looking at nautilus and metacity, which both get restarted by the session to see how they register/unregister. It's not apparent to me how they do it. I couldn't find any code in either that was responsible for registering, certainly they are not doing it how we are. So my big question is, does anyone know how nautilus/metacity are auto-restarted because I think we should do it the same way as they do not have the problems we have.

Aritchie (aritchie) wrote :

Hi Bill, this is just a thought and I may be way off base with this, but I also am running the UNE interface package on top of the Desktop Edition 10.10 and it on occasion - not often thoogh - the launcher and panel will crash and it has always restarted and I have never on logging out or shutting down had any processes refusing to end. My thought was that maybe you can take a look at that code and see what is going on there. Maybe it might trigger a few ideas. I no it know it does not use Qt or QMLbut maybe that would not make a differnece with this situation.

On Tuesday 15 March 2011 22:58:01 you wrote:
> This bug is related to bug #706248.
> After much debugging, it seems the problem is related to how we are
> registering unity-2d-launcher and unity-2d-panel with gnome-session. We
> are registering with gnome-session such that these two application can be
> restarted automatically by the session when they crash.
>
> The registration code is in libunity-2d-
> private/src/gnomesessionclient.cpp in method connectToSessionManager().
> On logout, the method queryEndSession() is called. Note that
> endSession() and stop() methods NEVER get called which doesn't seem
> correct.
>
> I was able to make the "Unknown process" dialog go away (at least couldn't
> make it fail in my testing) by changing the dbus call in queryEndSession()
> to async instead of sync, i.e.
> QDBusPendingCall call = iface.asyncCall("EndSessionResponse", true,
> ""); instead of:
> QDBusReply<void> reply = iface.call("EndSessionResponse", /* is_okay= */
> true, /* reason= */ "");

Makes sense. I am going to apply something like this.
>
> But even in changing call to async, the long delay still occurs on
> logout (bug 706248) so clearly we are still not doing something
> correctly. Commenting out the impl in connectToSessionManager() fixes
> both problems, but then launcher and panel won't restart on crash.

I recently noticed the launcher takes a long time to shutdown. I wonder if
this could be related.
>
> I'm looking at nautilus and metacity, which both get restarted by the
> session to see how they register/unregister. It's not apparent to me how
> they do it. I couldn't find any code in either that was responsible for
> registering, certainly they are not doing it how we are. So my big
> question is, does anyone know how nautilus/metacity are auto-restarted
> because I think we should do it the same way as they do not have the
> problems we have.

metacity session code is in core/session.c, but it uses the old, X11-based,
protocol which I have been told should be avoided. Quite a few applications do
it the way we do so I think we are on the right track but this kind of bug is
difficult to track, and I probably haven't looked at it long enough yet.

Bill Filler (bfiller) wrote :

little progress made here despite tons of debugging.
Here is what I do know:
- unity-2d-launcher and unity-2d-panel correctly registering with gnome-session and correctly providing a response to QueryEndSession() signal sent from org.gnome.SessionManager.ClientPrivate interface with EndSessionResponse() method
- gnome-session is receiving the EndSessionResponse()
- gnome-session then NEVER fires EndSession() signal back to unity-2d-*. This is the problem. Other clients who register with gnome-session (i.e. gnome-power-manager, gnome-keyring, polickit-1-gnome) and get the EndSession() signal and then call the EndSessionResponse() again which causes the disconnect. Without this happening we are running into either
a) the dialog being displayed saying unresponsive program
or
b) a 10 second timeout (as documented in http://people.gnome.org/~mccann/gnome-session/docs/gnome-session.html#org.gnome.SessionManager.ClientPrivate) before the session is killed.

I believe EndSession() signal is not being sent because gnome-session thinks we've inhibited the logout (based on messages I'm seeing when running gnome-session in debug mode). I haven't figured out why this is happening yet.

Attached is a log from running gnome-session in debug mode.

Bill Filler (bfiller) wrote :
Aritchie (aritchie) wrote :

Hmm, I don't know if this is of any consequence but I noticed when I run unity-2d with compiz and logout or shutdown it reports 2 processes not ending but if I run unity-2d with metacity and then logout or shutdown than only 1 unknown process refuses to end. I have switched back to metacity.

Aritchie (aritchie) wrote :

Actually I will have to change my previous observation. It appears that running with metacity, sometimes it is 2 processes that will not end and sometimes it is only 1. I noticed Bill that you also updated the metacity package back on February 9. Could it maybe also have something to do with changes you made there or is that totally unrelated? I am just trying to throw out some ideas to help.

Aritchie (aritchie) wrote :

Well actually, I do not think it would be now that I think about it since I ran unity-2d with compiz for a little bit and it was doing the same thing - so I doubt if it is anything to do with metacity.

Bill Filler (bfiller) wrote :

So this is figured out. What was happening was the launcher and panel processes were being destroyed before the handshake with gnome session manager was being initiated or finished.

Here is the sequence of messages on logout between gnomesessionclient.cpp and gnome-session via dbus
- client receives QueryEndSession signal from org.gnome.SessionManager.ClientPrivate
- client calls EndSessionResponse on same dbus interface
- client receives EndSession() signal
- client calls EndSessionResponse

If any this sequence does not complete, different results happen depending on where in the process it was interrupted.

There were two cases:
1) process killed before QueryEndSession signal received: in this case we'd get the "Unknown process" dialog
2) process killed after QueryEndSession but before EndSession(): in this case we'd encounter the 10 second delay before logout (bug 706248)

agateau has come up with an awesome fix, to not exit the main loop until we are finished processing the logout events. this has been tested and fixed both bugs.
The branch is here and will be committed soon:
lp:~agateau/unity-2d/wait-for-end-session

Changed in unity-2d:
status: In Progress → Fix Committed
Alex Chiang (achiang) on 2011-03-22
Changed in charlotte:
milestone: none → m4-rc2
Bill Filler (bfiller) wrote :

ran into problem again, proposed a new merge request with fix.

Changed in unity-2d:
status: Fix Committed → In Progress
Changed in unity-2d:
status: In Progress → Fix Committed
Changed in unity-2d:
status: Fix Committed → Fix Released
Alex Chiang (achiang) on 2011-03-24
Changed in charlotte:
importance: Undecided → High
assignee: nobody → Alex Chiang (achiang)
Florian Boucault (fboucault) wrote :

Fix has been backported from lp:unity-2d (natty) to lp:unity-2d/0.4 (maverick).

Changed in charlotte:
status: New → In Progress
Alex Chiang (achiang) on 2011-03-25
Changed in charlotte:
status: In Progress → Fix Committed
Sean Feole (sfeole) wrote :

I haven't seen this post 20110328-0

tags: added: cqa-verified
Alex Chiang (achiang) on 2011-03-30
Changed in charlotte:
status: Fix Committed → Fix Released
Sean Feole (sfeole) on 2011-06-24
tags: added: cqa-verified-gm
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers