[mir-only] infometric values are not updated

Bug #1234904 reported by Pat McGowan
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
unity-mir
Fix Released
High
Michael Terry
unity-mir (Ubuntu)
Fix Released
Critical
Unassigned
Saucy
Fix Released
Critical
Unassigned

Bug Description

The greeter shows everything as zero.

Disable Mir and real values are shown.

Related branches

Revision history for this message
Michael Terry (mterry) wrote :

In testing, the signal is emitted from the metrics daemon, but not handled by libmetricsoutput.

affects: unity8 (Ubuntu) → libusermetrics (Ubuntu)
Changed in libusermetrics (Ubuntu):
assignee: nobody → Pete Woods (pete-woods)
Revision history for this message
Pete Woods (pete-woods) wrote :

I don't think I have any control over signal handling in libusermetricsoutput.

Is the greeter process frozen somehow under Mir?

Revision history for this message
Pat McGowan (pat-mcgowan) wrote :

Its not frozen, tapping changes the display but the numbers are always zero

Revision history for this message
Olli Ries (ories) wrote :

importance critical, doesn't block switch to default

Revision history for this message
Pete Woods (pete-woods) wrote :

> Its not frozen, tapping changes the display but the numbers are always zero

I mean frozen when, say, when the camera app is in the foreground.

To risk sounding like a typical engineer, I strongly believe this is not a problem with libusermetrics. This library simply listens to DBus signals, and if something is stopping it for whatever reason, I don't think it can be fixed there.

I'd be concerned that all DBus signals to the greeter could be being blocked.

Revision history for this message
Michael Terry (mterry) wrote :

Pete, I didn't mean to give the impression of dumping it on your lap, but to ask if it made any sense to you either. :)

I agree with you that it's not likely to be a bug in libusermetrics itself. But this bug was usermetricsservice not being able to talk to libusermetricsoutput. I figured assigning to libusermetrics was closer to the real source of the problem than unity8 was.

I've looked into this, and thought I'd test the "frozen" angle. Adding a debug timer to libusermetricsoutput, it is definitely running while we're taking the photo and should be in a position to receive the signal.

I'm not sure why Mir would affect our ability to listen for the signal...

Revision history for this message
Pete Woods (pete-woods) wrote :

We know that synchronous DBus calls are making their way through. But they are handled in the current thread, with no message queueing or the like.

The sort of thing I'm thinking is that Mir has affect the threading model of unity8.

Could whatever Qt worker thread that normally processes the DBus message queue / Qt event queue be saturated / deadlocked / just not exist under Mir? I don't know Qt's internals well enough to know how to test for this.

Revision history for this message
Michael Terry (mterry) wrote :

I just tried, and letting usermetricsservice to run as root instead of the usermetrics user makes things work. I don't know how enabling Mir would affect the permissions model for receiving signals from usermetrics...

Revision history for this message
Michael Terry (mterry) wrote :

OK, this seems to be a problem with unity-mir's running its own DBus service in a different thread than the rest of unity8. I don't think the DBus internals of Qt can be spread across threads.

affects: libusermetrics (Ubuntu) → unity-mir (Ubuntu)
Changed in unity-mir (Ubuntu):
assignee: Pete Woods (pete-woods) → nobody
status: New → Confirmed
Revision history for this message
Pete Woods (pete-woods) wrote :

That's definitely the case. You absolutely have to run all the DBus stuff on the same thread or it simply breaks. I've suffered that problem before.

Revision history for this message
Michael Terry (mterry) wrote :

Well, maybe not a thread problem, but when I stop unity-mir from handling com.canonical.Unity.Screen, everything works.

Revision history for this message
Michael Terry (mterry) wrote :

Ah, god. The problem was that unity-mir installed a dbus policy file that denied everyone but root the ability to send messages/signals to whomever owned com.canonical.Unity.Screen.

This is because it used "send_destination=com.canonical.Unity.Screen" instead of "send_interface=com.canonical.Unity.Screen", because presumably its intent was to stop anyone but root from using that interface.

Branch coming up.

Revision history for this message
Pete Woods (pete-woods) wrote :

Awesome work!

Omer Akram (om26er)
Changed in unity-mir:
importance: Undecided → High
status: New → Confirmed
status: Confirmed → In Progress
assignee: nobody → Michael Terry (mterry)
tags: added: rls-s-incoming
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

Fix committed into lp:unity-mir at revision 108, scheduled for release in unity-mir, milestone phone-v1-freeze

Changed in unity-mir:
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package unity-mir - 0.1+13.10.20131009.3-0ubuntu2

---------------
unity-mir (0.1+13.10.20131009.3-0ubuntu2) saucy; urgency=low

  * No change rebuild to drop upstart-app-launch dep; sigh.
 -- Loic Minier <email address hidden> Thu, 10 Oct 2013 04:12:30 +0200

Changed in unity-mir (Ubuntu Saucy):
status: Confirmed → Fix Released
Michał Sawicz (saviq)
Changed in unity-mir:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.