Bug 972257 - GError: The name :1.0 was not provided by any .service files
GError: The name :1.0 was not provided by any .service files
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: dogtail (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Vitezslav Humpa
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-07 22:37 EDT by Matthias Clasen
Modified: 2014-06-12 08:16 EDT (History)
12 users (show)

See Also:
Fixed In Version: dogtail-0.9.0-1.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-04-18 11:40:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthias Clasen 2013-06-07 22:37:53 EDT
None of the dogtail example scripts work here.

Here is the output of the filechooser-stress-test:


python /usr/share/doc/dogtail-0.8.1/examples/filechooser-stress-test.py 

** (filechooser-stress-test.py:6931): WARNING **: AT-SPI: Error in GetItems, sender=org.freedesktop.DBus, error=The name :1.0 was not provided by any .service files
Creating logfile at /tmp/dogtail/logs/filechooser-stress-test_20130607-223620_debug ...
Traceback (most recent call last):
  File "/usr/share/doc/dogtail-0.8.1/examples/filechooser-stress-test.py", line 10, in <module>
    gedit = root.application('gedit')
  File "/usr/lib/python2.7/site-packages/dogtail/tree.py", line 998, in application
    return root.findChild(predicate.IsAnApplicationNamed(appName),recursive=False)
  File "/usr/lib/python2.7/site-packages/dogtail/tree.py", line 781, in findChild
    result = self._fastFindChild(pred.satisfiedByNode, recursive)
  File "/usr/lib/python2.7/site-packages/dogtail/tree.py", line 748, in _fastFindChild
    if pred(child): return child
  File "/usr/lib/python2.7/site-packages/dogtail/predicate.py", line 98, in satisfiedByNode
    return node.roleName=='application' and stringMatches(self.appName, node.name)
  File "/usr/lib64/python2.7/site-packages/gi/types.py", line 113, in function
    return info.invoke(*args, **kwargs)
GError: The name :1.0 was not provided by any .service files

Exception OSError: OSError('Dogtail unlock: not locked',) in <bound method Lock.__del__ of <dogtail.utils.Lock object at 0x1a0af10>> ignored


app-startup.py produces very similar output:

python /usr/share/doc/dogtail-0.8.1/examples/appstartup.py gedit

** (appstartup.py:6956): WARNING **: AT-SPI: Error in GetItems, sender=org.freedesktop.DBus, error=The name :1.0 was not provided by any .service files

(gedit:6960): GtkSourceView-WARNING **: no color named 'black'

(gedit:6960): GtkSourceView-WARNING **: no color named 'black'
Traceback (most recent call last):
  File "/usr/share/doc/dogtail-0.8.1/examples/appstartup.py", line 25, in <module>
    appStartup(binary)
  File "/usr/share/doc/dogtail-0.8.1/examples/appstartup.py", line 17, in appStartup
    pid = run(binary)
  File "/usr/lib/python2.7/site-packages/dogtail/procedural.py", line 370, in run
    focus.application(application)
  File "/usr/lib/python2.7/site-packages/dogtail/procedural.py", line 66, in __call__
    app = self.desktop.findChild(pred, recursive = False, retry = False)
  File "/usr/lib/python2.7/site-packages/dogtail/tree.py", line 781, in findChild
    result = self._fastFindChild(pred.satisfiedByNode, recursive)
  File "/usr/lib/python2.7/site-packages/dogtail/tree.py", line 748, in _fastFindChild
    if pred(child): return child
  File "/usr/lib/python2.7/site-packages/dogtail/predicate.py", line 98, in satisfiedByNode
    return node.roleName=='application' and stringMatches(self.appName, node.name)
  File "/usr/lib64/python2.7/site-packages/gi/types.py", line 113, in function
    return info.invoke(*args, **kwargs)
GError: The name :1.0 was not provided by any .service files

Exception OSError: OSError('Dogtail unlock: not locked',) in <bound method Lock.__del__ of <dogtail.utils.Lock object at 0x206ca90>> ignored
Comment 1 Vitezslav Humpa 2013-06-14 06:12:20 EDT
We've hit it too. Looks like this is a recent update change/config problem that breaks the a11y. It should work with a clean new user or purged config. This was Rhel though, could you please try again with a new user on Fedora?
Comment 2 Kamil Páral 2013-07-29 12:20:54 EDT
I see the same traceback. But when I try it in a LiveCD it does not crash. Probably connected to an existing config, yes.
Comment 3 Kamil Páral 2013-08-01 16:08:30 EDT
Vitezslav, which config files should I try to purge to get dogtail working with my existing user profile? Thanks.
Comment 4 Kamil Páral 2013-08-01 16:14:26 EDT
I see the same error when running accerciser:

** (accerciser:3550): WARNING **: AT-SPI: Error in GetItems, sender=org.freedesktop.DBus, error=The name :1.0 was not provided by any .service files
Traceback (most recent call last):
  File "/usr/lib/python3.3/site-packages/accerciser/accessible_treeview.py", line 327, in _popOnIdle
    row = self._buildRow(child)
  File "/usr/lib/python3.3/site-packages/accerciser/accessible_treeview.py", line 454, in _buildRow
    role = accessible.getLocalizedRoleName()
  File "/usr/lib64/python3.3/site-packages/gi/types.py", line 113, in function
    return info.invoke(*args, **kwargs)
gi._glib.GError: The name :1.0 was not provided by any .service files

Traceback (most recent call last):
  File "/usr/lib/python3.3/site-packages/pyatspi/registry.py", line 193, in eventWrapper
    return callback(event)
  File "/usr/lib/python3.3/site-packages/accerciser/accessible_treeview.py", line 701, in _accEventChildChanged
    self._addChild(iter, event.source)
  File "/usr/lib/python3.3/site-packages/accerciser/accessible_treeview.py", line 750, in _addChild
    row = self.model._buildRow(new_child)
  File "/usr/lib/python3.3/site-packages/accerciser/accessible_treeview.py", line 454, in _buildRow
    role = accessible.getLocalizedRoleName()
  File "/usr/lib64/python3.3/site-packages/gi/types.py", line 113, in function
    return info.invoke(*args, **kwargs)
gi._glib.GError: The name :1.0 was not provided by any .service files


at-spi bug?
Comment 5 Vitezslav Humpa 2013-08-19 07:51:40 EDT
Probably late, though for us it was anything to do with dconf. Didn't manage to figure out what keys or what in specific it was. Fortunately this doesn't seem to occur anymore with updates. Was 3.6->3.8 business.
Comment 6 Pranav Kant 2014-03-16 03:43:34 EDT
While running 'make check' on gnome-weather, the written dogtail tests are failing with same error. 

In this case also, error is erratic. Sometimes when I boot my pc after a long time, it just resolves and UI tests works fine. The next time I boot, there is no gurrantee that the tests will work, they usually fail with this concerned error.

I also suspect the config files to be the cause but do not know how I can clean the config files for modules like dogtail, at-spi2-atk, at-spi2-core. I am running the 'make test' inside jhbuild shell. I have also jhbuilt dogtail, at-spi2-atk, at-spi2-core modules.
Comment 7 Vitezslav Humpa 2014-03-19 10:45:57 EDT
Well, this whole issue is somewhat random as to what brings the bus to behave this way. There's no apparent reason why this happens to an user. Once the bus breaks this way for a user it's reproducible for some time and them may go back to normal. 

Clearing configs or working with a new user is just a workaround that doesn't tell us much about the cause. This likely lies with the at-spi/pyatspi in relation to how the session bus gets run. Not an dogtail issue, if you work with plain pyatspi, you hit this as well. Switching to at-spi, please ping the at-spi guys if you need this escalated. They may also know better what specific configs to try clear out, dogtail pretty much doesn't store any user-wide ones.
Comment 8 Debarshi Ray 2014-03-20 08:36:34 EDT
Worth mentioning that Orca works without any issues.
Comment 9 Joanmarie Diggs 2014-03-20 08:54:21 EDT
I've seen this before.

When I experienced the problem, what was taking place was some app somewhere was showing up as dead -- at least insofar as the at-spi2 registry is concerned. Accerciser was getting tripped up and failing to build its tree of accessible apps and objects.

Dead apps are bad and this problem should of course be fixed at the source. What I hoped to be able to do is call get_process_id () on the accessible Application. But that not only failed to provide the answer, it crashed the app in which you did the call. Mike fixed the crashed-your-app issue [1], but that's not going to magically give you the process id of the dead app. So I don't know how to hunt down the actual/original bug source. :( But....

What Orca does, and what a quick hack I did for my local copy of Accerciser does, is check if app.name == ''. You can do this safely even without Mike's fix for get_process_id (). If that returns True, you have a dead app hanging around on the registry. You do not want to touch that app. It is not your app. It has no useful information. Dance around it gracefully. If you add this sanity check to dogtail's and accerciser's tree-building functionality, things will start working as you expect and you can resume getting things done.

Perhaps at-spi2 itself should do some periodic checks to see if dead apps are hanging around and clean them up so such sanity checks are not needed. But having maintained Orca for a number of years, trust me when I tell you that there will always be some badly-behaved app somewhere and a simple sanity check is worth adding to your testing tools. ;)

[1] https://git.gnome.org/browse/at-spi2-core/commit/?id=2554a07c0bbee7defef5b2fca3a420d6cf42a770
Comment 10 Debarshi Ray 2014-03-20 09:44:42 EDT
Thanks for that insight Joanie. Shall we re-assign it back to dogtail now?
Comment 11 Vitezslav Humpa 2014-03-20 10:38:56 EDT
Hi Joanmarie, indeed looks like a solid pointer to the cause of this particular issue. I am testing a hackfix for this to move along such damaged apps when doing a query in dogtail. Still keeps being an at-spi problem, but could help bypass this for dogtail.

Rishi, this being just a dogtail hackfix of the original a11y issue, I'd keep the bug itself with at-spi if someone ever manages to get to the very root of this.
Comment 12 Vitezslav Humpa 2014-03-20 10:52:44 EDT
On the other hand, we don't really know what component(crashing app?) is to blame here and at-spi might not be the proper one either. So let's take this bug by the original dogtail-related meaning and file a new one if issue reappears elsewhere.
Comment 13 Joanmarie Diggs 2014-03-20 11:01:34 EDT
There's currently talk about putting a sanity check in at-spi2 itself (i.e. upstream gnome). When there's a conclusion, I'll update this bug for the sake of documentation.
Comment 14 Joanmarie Diggs 2014-03-20 11:29:17 EDT
Conclusions from the GNOME Accessibility Team meeting: We will add a check to at-spi2 for the 3.12.1 release: https://bugzilla.gnome.org/show_bug.cgi?id=726781

That won't solve the problem for earlier clients, however, so the dogtail hackfix is still recommended.
Comment 15 Vitezslav Humpa 2014-03-20 11:38:40 EDT
Indeed we'll put the check in dogtail too, so that the issue gets tackled with older versions of at-spi2 as well. Thanks again for the insight and info on this.
Comment 16 Vitezslav Humpa 2014-04-15 10:42:29 EDT
Finally got myself a session broken nicely in this fashion and fixed (workarounded) this upstream as 4e5e19a17b7df43 (framework) and 5c1e1f62935188 (sniff). Landing in 0.8.3
Comment 17 Fedora Update System 2014-04-16 09:55:41 EDT
dogtail-0.9.0-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dogtail-0.9.0-1.fc20
Comment 18 Fedora Update System 2014-04-16 09:57:01 EDT
dogtail-0.9.0-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/dogtail-0.9.0-1.fc19
Comment 19 Fedora Update System 2014-04-18 11:34:53 EDT
Package dogtail-0.9.0-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dogtail-0.9.0-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-5297/dogtail-0.9.0-1.fc19
then log in and leave karma (feedback).
Comment 20 Fedora Update System 2014-04-18 11:40:43 EDT
dogtail-0.9.0-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 yannack 2014-06-12 07:35:15 EDT
Hello,
I have run into this issue, but in an Xvfb instance. This means that the message was not about ":1.0" but ":1.4" so the workaround failed, since the patch basically checks on the exact string:

if 'name :1.0 was not provided' in e.message:

I manually fixed it on my instance, so it can work on many display. But just so this is out there, I am letting you guys know. This is what I did, but feel free to improve: I replaced the above tests with this:

if re.match("name :[0-9]+\.[0-9]+ was not provided", e.message):

Hope this helps,
Yannick
Comment 22 Vitezslav Humpa 2014-06-12 08:16:44 EDT
Hi Yannick, thanks for the multi-screen observation! I am patching that in upstream dogtail and it will land in 0.9.1.

Note You need to log in before you can comment on or make changes to this bug.