Indicator is not starting when launched for the first time.

[sajonCC]

Hi,

First of all I would like to thank you for this applet. It's great.

I've found an issue with starting openvpn3-indicator for the first time after computer reboot. I'm not a programmer so I'm not sure how to solve the problem.

This is what I can see in the console when starting for the first time - applet will do not run.

❯ openvpn3-indicator

(openvpn3-indicator:62865): Gtk-WARNING **: 10:13:49.309: Theme parsing error: gtk-dark.css:1710:67: Junk at end of value for background-image

(openvpn3-indicator:62865): Gtk-WARNING **: 10:13:49.310: Theme parsing error: gtk-dark.css:2822:2: Expected semicolon

(openvpn3-indicator:62865): Gtk-WARNING **: 10:13:49.311: Theme parsing error: gtk-dark.css:4591:34: Expected a valid selector
Traceback (most recent call last):
  File "/usr/local/bin/openvpn3-indicator/openvpn3_indicator/application.py", line 123, in on_startup
  File "/usr/lib/python3.11/site-packages/dbus/proxies.py", line 72, in __call__
    return self._proxy_method(*args, **keywords)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/site-packages/dbus/connection.py", line 634, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.UnknownMethod: Object does not exist at path “/net/openvpn/v3/configuration”`

When starting for the second time - applet is starting but still throwing some errors.

 openvpn3-indicator

(openvpn3-indicator:62902): Gtk-WARNING **: 10:14:06.626: Theme parsing error: gtk-dark.css:1710:67: Junk at end of value for background-image

(openvpn3-indicator:62902): Gtk-WARNING **: 10:14:06.627: Theme parsing error: gtk-dark.css:2822:2: Expected semicolon

(openvpn3-indicator:62902): Gtk-WARNING **: 10:14:06.628: Theme parsing error: gtk-dark.css:4591:34: Expected a valid selector

(openvpn3-indicator:62902): Gdk-WARNING **: 10:14:23.687: Server is missing xdg_foreign support
[62953, Main Thread] WARNING: Theme parsing error: gtk-dark.css:1710:67: Junk at end of value for background-image: 'glib warning', file /home/abuild/rpmbuild/BUILD/firefox-127.0/toolkit/xre/nsSigHandlers.cpp:187

(firefox:62953): Gtk-WARNING **: 10:14:23.757: Theme parsing error: gtk-dark.css:1710:67: Junk at end of value for background-image
[62953, Main Thread] WARNING: Theme parsing error: gtk-dark.css:2822:2: Expected semicolon: 'glib warning', file /home/abuild/rpmbuild/BUILD/firefox-127.0/toolkit/xre/nsSigHandlers.cpp:187

(firefox:62953): Gtk-WARNING **: 10:14:23.758: Theme parsing error: gtk-dark.css:2822:2: Expected semicolon
[62953, Main Thread] WARNING: Theme parsing error: gtk-dark.css:4591:34: Expected a valid selector: 'glib warning', file /home/abuild/rpmbuild/BUILD/firefox-127.0/toolkit/xre/nsSigHandlers.cpp:187

(firefox:62953): Gtk-WARNING **: 10:14:23.759: Theme parsing error: gtk-dark.css:4591:34: Expected a valid selector

Info about my system:

OS: openSUSE Tumbleweed-Slowroll x86_64 
Host: 21K30009US ThinkPad T14 Gen 4 
Kernel: 6.9.7-1-default 
Uptime: 23 hours, 44 mins 
Packages: 3438 (rpm), 13 (flatpak) 
Shell: bash 5.2.26 
Resolution: 1920x1080 
DE: Plasma 6.1.1 
WM: kwin 
Theme: Cameo-Dark-Green [GTK2/3] 
Icons: Win11-dark [GTK2/3] 
Terminal: konsole 
CPU: AMD Ryzen 7 PRO 7840U w/ Radeon 780M Graphics (16) @ 5.132GHz 
GPU: AMD ATI 64:00.0 Phoenix1 
Memory: 17595MiB / 30778MiB 

[dsommers]

I think I see the issue.

In application.py the D-Bus connection is setup and in line131 (latest git master, commit 49922ce59c) the following line is called:

cmgr_version = str(cmgr_prop.Get('net.openvpn.v3.configuration','version'))

Before that, the self.dbus.get_object() and dbus.Interface() calls prepares the cmgr_prop object. The tricky detail here is that these two calls may not necessarily trigger the net.openvpn.v3.configuration service to start. If they do, the cmgr_prop.Get() calls comes too quickly, before the service has been able to properly start up and settle.

These calls here is actually doing something outside of the openvpn3.ConfigurationManager class in the openvpn3 Python module. All the methods in this class will call self.__ping() before doing any calls - just to ensure the service is available.

I'm also wondering if we should expose a new GetVersion() method or maybe even re-implement the CheckFeatures() and the set_feature_flags() helper methods from the C++ proxy in the Python code. That would give a standard way to check for features.

These new methods are a stretch goal to actually solve the crux of this particular issue .... since it's about retrieving information about features openvpn3-indicator requires or have support for.

As a very ugly short-term fix for openvpn3-indicator right now ... would be to just call the private __ping() method ... which can be inserted around line 126-ish:

self.config_manager._ConfigurationManager__ping()

Thoughts? Would you be willing to try porting the CheckFeatures() to the openvpn3 Python module, @grzegorz-gutowski ?

[grzegorz-gutowski]

@sajonCC How did you install openvpn3-indicator. You seem to be running a little older code. In newer versions, the whole Get Backend Version code is run with proper exception catching.

@dsommers Nevertheless, I added a ping as you suggested.

@dsommers I was hoping to propose a more pytonish API for openvpn3 at some point in the future. Let me think about it a little more.

[dsommers]

@grzegorz-gutowski I'm really open to improve the openvpn3 module all together ... I've unfortunately just been way too busy to dig into it myself yet. I'm also open to extract it out of the openvpn3-linux project and have it as a separate Python specific project which can be published in PyPi too. That could help to unleash the Python updates from the openvpn3-linux release cadence.

[sajonCC]

@sajonCC How did you install openvpn3-indicator. You seem to be running a little older code. In newer versions, the whole Get Backend Version code is run with proper exception catching.

Source code, it was couple of weeks ago and I didn't update it yet (version devel-20240415172226-a00ecaa).

I just updated in to the last code from the git. I will test it and let you know.

[grzegorz-gutowski]

@grzegorz-gutowski I'm really open to improve the openvpn3 module all together ... I've unfortunately just been way too busy to dig into it myself yet. I'm also open to extract it out of the openvpn3-linux project and have it as a separate Python specific project which can be published in PyPi too. That could help to unleash the Python updates from the openvpn3-linux release cadence.

I'm ready to invest some time into this. I already have some prototypes, but I'm not happy with them yet.

[dsommers]

I'm ready to invest some time into this. I already have some prototypes, but I'm not happy with them yet.

You know how to reach me! :wink: