Activating the Hamster plugin without Hamster present (or missing permissions in Flatpak) will cause tracebacks on startup, crashing / preventing GTG's future launches with `DBus.Error.NameHasNoOwner` and `DBus.Error.ServiceUnknown`

[jorgeecardona]

Hi, I have installed GTG 0.5 via flapak, I am getting the following error the first time I run the app with flatpak run org.gnome.GTG

Traceback (most recent call last):
  File "/app/lib/python3.8/site-packages/dbus/bus.py", line 175, in activate_name_owner
    return self.get_name_owner(bus_name)
  File "/app/lib/python3.8/site-packages/dbus/bus.py", line 359, in get_name_owner
    return self.call_blocking(BUS_DAEMON_NAME, BUS_DAEMON_PATH,
  File "/app/lib/python3.8/site-packages/dbus/connection.py", line 650, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NameHasNoOwner: org.freedesktop.DBus.Error.NameHasNoOwner

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/app/lib/python3.8/site-packages/GTG/gtk/application.py", line 123, in do_activate
    self.init_shared()
  File "/app/lib/python3.8/site-packages/GTG/gtk/application.py", line 162, in init_shared
    self.init_plugin_engine()
  File "/app/lib/python3.8/site-packages/GTG/gtk/application.py", line 188, in init_plugin_engine
    self.plugin_engine.activate_plugins()
  File "/app/lib/python3.8/site-packages/GTG/core/plugins/engine.py", line 201, in activate_plugins
    plugin.instance.activate(api)
  File "/app/lib/python3.8/site-packages/GTG/plugins/hamster/hamster.py", line 155, in activate
    self.hamster = dbus.SessionBus().get_object('org.gnome.Hamster',
  File "/app/lib/python3.8/site-packages/dbus/bus.py", line 239, in get_object
    return self.ProxyObjectClass(self, bus_name, object_path,
  File "/app/lib/python3.8/site-packages/dbus/proxies.py", line 248, in __init__
    self._named_service = conn.activate_name_owner(bus_name)
  File "/app/lib/python3.8/site-packages/dbus/bus.py", line 180, in activate_name_owner
    self.start_service_by_name(bus_name)
  File "/app/lib/python3.8/site-packages/dbus/bus.py", line 275, in start_service_by_name
    return (True, self.call_blocking(BUS_DAEMON_NAME, BUS_DAEMON_PATH,
  File "/app/lib/python3.8/site-packages/dbus/connection.py", line 650, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: org.freedesktop.DBus.Error.ServiceUnknown

This happen the first time I run the app, if I use a different console to run the app it opens without the error. The same happen if I click in the app's icon, the first time gnome just wait for the app to open but no window shows up, if I click again in the icon then the window shows up properly.

I have a GNOME Shell 3.38.4 on a Debian sid. Let me know if you need more info.

[nekohayo]

Huh, this is odd... I have no idea what this might mean, and I haven't encountered that (apparently others didn't either). Is that still happening consistently for you, or did you just happen to have a broken d-bus on that particular day that got fixed by a reboot?

[jorgeecardona]

It happens consistently; my current gnome installation runs flawlessly, this is the only thing failing at the moment. I can give you versions of installed packages or content of files on request.

[Neui]

It seems to be caused by the Hamster plugin. Since it says "ServiceUnknown" I guess you don't have Hamster installed. That it shouldn't block the execution is a bug in my opinion. Try disabling the plugin/extension.

[nekohayo]

Aaah, I can indeed reproduce this now, so retitling this ticket for clarity. The trick is to try to activate the plugin without Hamster present on your system. When you do that, you'll get a traceback (that gets caught by the new ErrorPopup module and traceback handler GUI), which appears non-fatal at first, but the next time you try to launch GTG it will turn into a fatal traceback that prevents launch, with output exactly as @jorgeecardona reported above. So perhaps this is a bug @flavin could help with!

The workaround, if any user is encountering this problem for the time being, is to edit the gtg.conf file in the config directory, and remove "hamster" from the activated plugins list.

[nekohayo]

As an additional note: GTG should also probably have a defensive plugin mechanism that doesn't save the activation state of plugins if an error occurs while trying to activate them, but I don't know how hard that would be to accomplish (or maybe it's just a matter of putting the whole plugin activation call into a giant try-except catch to avoid writing that config when any exception occurs)...