Fails to load DBus configuration (configuration exists)

[leonkacowicz-atomic]

When I run openvpn3-indicator it fails with the following message:

$ openvpn3-indicator
Traceback (most recent call last):
  File "/usr/local/bin/openvpn3-indicator/openvpn3_indicator/application.py", line 123, in on_startup
  File "/usr/lib/python3.12/site-packages/dbus/proxies.py", line 72, in __call__
    return self._proxy_method(*args, **keywords)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/site-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.12/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”

[grzegorz-gutowski]

It looks as if openvpn3 service is not running. Please make sure you installed and started openvpn3-linux. I should probably detect it on startup and report it in some more readable way...

[leonkacowicz-atomic]

It is running and working correctly (connectivity is totally fine)

[leonkacowicz-atomic]

Found the solution: sudo systemctl start net.openvpn.v3.configuration.slice solve the problem

[dsommers]

That sounds like a very unexpected solution. The config manager should automatically when needed; it defaults to exit after some idle time.

What does the output of these commands give you?

  $ openvpn3 version
  $ openvpn3-admin version --services

[leonkacowicz-atomic]

Just to be clear, it is working fine now. It just needed some push. I think some config wasn't stored or read correct until I did that above.

❯ openvpn3 version
openvpn3-linux makepkg:4f37952340f0e5d3 (openvpn3)
OpenVPN core 3.git:HEAD:03236ed7 linux x86_64 64-bit
Copyright (C) 2012-2022 OpenVPN Inc. All rights reserved.

❯ sudo openvpn3-admin version --services
OpenVPN 3 D-Bus services:

  - Client backend starter service
    openvpn3-service-backendstart:           makepkg:4f37952340f0e5d3

  - Configuration Service
    openvpn3-service-configmgr:              makepkg:4f37952340f0e5d3

  - Log Service
    openvpn3-service-log:                    makepkg:4f37952340f0e5d3

  - Network Configuration Service
    openvpn3-service-netcfg:                 makepkg:4f37952340f0e5d3

  - Session Manager Service
    openvpn3-service-sessionmgr:             makepkg:4f37952340f0e5d3

[dsommers]

The version you run is using a brand new C++ integration for D-Bus. I've seen that in some occasional situations, the service might not always have all the D-Bus objects ready before the service is announced as available by the D-Bus daemon.

This is due to the new integration library making use of multi-threading; the prior implementation was mostly single threaded. When the configuration manager starts, it will parse all the persistent configurations first which then creates a D-Bus object per configuration profile file. So while the initial main thread does this, the service is made available on the bus and starts accepting requests in new threads being started automatically in parallel to the initial main thread.

There are a few things which can be done to improve this, and I'll schedule that for the v23 release.

[leonkacowicz-atomic]

Interesting, so this is an actual bug and not just a glitch.

[dsommers]

Yes, this is a bug from a user experience perspective. But I find this labeling less important in the bigger picture - as then it is more a question of where the bug is from a technical perspective. It is an unexpected behaviour for some code not considering this new situation.

This appeared due to the refactored configmgr service being more efficient but didn't take into consideration the delay in getting persistent configuration parsed as that happens in parallel now. So is it a bug because the new configmgr service accepts requests before all data is parsed? Or is it a bug on the "calling side" which doesn't try again in a bit to see if the missing object was a temporary or permanent error? From a D-Bus perspective both of these perspectives are valid, as it has weak guarantees when objects should be available and consumable. Or is it a regression bug because the behaviour in general is now different than in prior versions?

Regardless of all this, I see more ways to solve this. I just need to decide what might be the overall better approach.