Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AppletManager doesn't know what to do when a D-Bus call fails #7

Open
jtgans opened this issue May 9, 2021 · 3 comments · Fixed by #21
Open

AppletManager doesn't know what to do when a D-Bus call fails #7

jtgans opened this issue May 9, 2021 · 3 comments · Fixed by #21
Labels
bug Something isn't working help wanted Extra attention is needed release blocker This blocks our next release
Milestone

Comments

@jtgans
Copy link
Owner

jtgans commented May 9, 2021

Right now the AppletManager is pretty rough, and has no idea what to do and simply dumps an exception when one of the following happens:

  • An applet on D-Bus dies off
  • An applet on D-Bus throws an exception in its D-Bus method handler

At the moment, this is okay-ish since we're still pre-alpha code, but obviously it's not ideal. We need some way of tracking the applet peers on D-Bus. Maybe something like this:

  1. Applets register D-Bus objects using the interface com.theonelab.g13.Applet under the path /com/theonelab/g13/Applet/AppletName
  2. AppletManager uses the list of objects under /com/theonelab/g13/Applet/... as it's literal dictionary of applets available every single time it needs to do something with one. IOW, it polls D-Bus for applets and does a loose mapping between applet object name and its internal list of "registered applets".

This would reduce some of the sources of the above two problems, but ultimately, I think we need lots of exception handling written around D-Bus proxies. Maybe a new class that wraps dbus.proxy.ObjectProxy to handle these things more gracefully?

@jtgans jtgans added bug Something isn't working help wanted Extra attention is needed good first issue Good for newcomers labels May 9, 2021
@jtgans jtgans added this to the 1.0 milestone May 9, 2021
@jtgans jtgans added the release blocker This blocks our next release label May 9, 2021
@jtgans
Copy link
Owner Author

jtgans commented May 9, 2021

We can probably make use of the org.freedesktop.DBus NameOwnerChanged signal like the way D-Feet does as a means for monitoring peer connects/disconnects and liveness tests on both sides of the Applet/AppletManager equation. See also https://gitlab.gnome.org/GNOME/d-feet/-/blob/master/src/dfeet/bus_watch.py#L146

@jtgans
Copy link
Owner Author

jtgans commented May 9, 2021

This isn't totally fixed -- there are still errors occuring during a crash or kill of an applet:

Failed to unpresent Switcher: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.1664 was not provided by any .service files
senders is {<g13gui.applet.switcher.Switcher object at 0x7f9efe9e1130>: 'Switcher', <ProxyObject wrapping <dbus._dbus.SessionBus (session) at 0x7f9efe9d99f0> :1.1658 /com/theonelab/g13/Applet at 0x7f9efc7e2580>: 'Profiles', <ProxyObject wrapping <dbus._dbus.SessionBus (session) at 0x7f9efe9d99f0> :1.1665 /com/theonelab/g13/Applet at 0x7f9efc69ebb0>: 'Clock'}
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/home/jtgans/Projects/g13/g13gui/applet/manager.py", line 52, in activeApplet
    self._activeApplet.Unpresent()
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 652, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.ServiceUnknown: The name :1.1664 was not provided by any .service files

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.8/threading.py", line 932, in _bootstrap_inner
    self.run()
  File "/home/jtgans/Projects/g13/g13gui/g13/manager.py", line 253, in run
    self._signalSpecialKeys(reportBuffer)
  File "/home/jtgans/Projects/g13/g13gui/g13/manager.py", line 324, in _signalSpecialKeys
    self._appletManager.onKeyPressed(key)
  File "/home/jtgans/Projects/g13/g13gui/applet/manager.py", line 93, in onKeyPressed
    self.activeApplet = 'Switcher'
  File "/home/jtgans/Projects/g13/g13gui/applet/manager.py", line 55, in activeApplet
    self._removeActiveApplet()
  File "/home/jtgans/Projects/g13/g13gui/applet/manager.py", line 74, in _removeActiveApplet
    name = senders[self._activeApplet]
KeyError: <ProxyObject wrapping <dbus._dbus.SessionBus (session) at 0x7f9efe9d99f0> :1.1664 /com/theonelab/g13/Applet at 0x7f9efc7bd3a0>

@jtgans jtgans reopened this May 9, 2021
@jtgans
Copy link
Owner Author

jtgans commented Oct 29, 2023

I managed to fix the above traceback by adding some try..except code around the _removeActiveApplet code, but it's still not ideal. If the applet crashes or dies out, it can sometimes cross the DBus IPC barrier and kill the manager thread, or just stall out the applet UI (since the manager doesn't auto-unpresent when an applet crashes out).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed release blocker This blocks our next release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant