Deal better with DBus.Error.ServiceUnknown errors

Bug #1020572 reported by Sebastien Bacher on 2012-07-03
This bug affects 1 person
Affects Status Importance Assigned to Milestone
apport (Ubuntu)
Martin Pitt

Bug Description

Looking to we get a lot of DbusException errors on some of our python services (jockey, oneconf, software-properties, ubuntu-sso-client, ...)

Those bugs tend to:
- not be that useful to figure the real issue
- create lot of noise for users
- be sign of setup problem rather than software bugs

We should aim at making those bugs useful, if we can't make them useful we should stop spamming the users about them since there is no point to trigger system error dialogs when there is no visible error and when the report sent is not useful

Taking a jockey issue as an example

"Traceback (most recent call last):
  File "/usr/bin/jockey-gtk", line 418, in <module>
  File "/usr/lib/python2.7/dist-packages/jockey/", line 470, in run
  File "/usr/lib/python2.7/dist-packages/dbus/", line 145, in __call__
  File "/usr/lib/python2.7/dist-packages/dbus/", line 651, in call_blocking
    message, timeout)
DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.68 was not provided by any .service files"

That basically tells us the service dbus activation is buggy, but doesn't really inform us on the issue....

Things we should be able to get infos on:
- is the target service installed and available (could be a missing depends)
- is the service running or does it fail to start for a reason (is there a log we can check for details on the reason)
- your ideas...

Martin Pitt (pitti) on 2012-07-03
Changed in apport (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

When writing test cases for the ServiceUnknown and NoReply variants I realized that the stack trace for NoReply does not tell us the D-BUS name it was trying to connect to, so for the time being we cannot collect additional information about that. For ServiceUnknown we do know the name though, and can detect whether any .service file provides the name and whether that service is running. Retitling the bug accordingly.

summary: - Deal better with DbusException errors
+ Deal better with DBus.Error.ServiceUnknown errors
Changed in apport (Ubuntu):
status: Triaged → In Progress
Martin Pitt (pitti) wrote :
Changed in apport (Ubuntu):
status: In Progress → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apport - 2.3-0ubuntu3

apport (2.3-0ubuntu3) quantal; urgency=low

  * Merge from trunk:
    - For org.freedesktop.DBus.Error.ServiceUnknown
      exceptions, add a 'DbusErrorAnalysis' field to the report which points
      out whether any .service file provides the service it tried to talk to,
      and whether the processes for those are running. This helps to determine
      the root cause for such errors (missing dependencies, broken .service
      files, talking to the wrong bus, etc.) (LP: #1020572)
    -, attach_alsa(): Use when available. Thanks
      David Henningson.
    - ui tests, test_wait_for_pid(): Fix eternal hang when running as root.
    - testsuite: Fix ResourceWarnings when running with Python 3.
  * debian/control, debian/tests/control: Add gvfs-daemons as build/test
    dependency, as test_python_crashes uses it as an example for handling
    python-dbus exceptions.
 -- Martin Pitt <email address hidden> Tue, 10 Jul 2012 14:58:45 +0200

Changed in apport (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers