On 2023-09-12 10:49, Colomban Wendling wrote:
All that is a bit confusing to me, but let me try ton understand: - On a system using dbus-broker, when logged in under GNOME, test fails? - On *the same system*, but logging-in through SSH works!??
Yes, that's what I've observed in a Fedora 38 VM.
That's worrying, as it suggests the running environment has too much influence on the test run, which is not good.However, IIUC you suggest it might be a dbus/dbus-borken conflict somehow?
That's what it looked like to me during first analysis.What might be happening is that at-spi-bus-launcher detects a systemd environment that makes it think running dbus-broker should work, but something about the systemd/D-Bus environment in the virtual X session provided by xfvb-run and dbus-launch doesn't match what's expected/required.
See also this comment in the at-spi-bus-launcher source code [1]: /* This detects whether we are running under systemd. We only try to * use dbus-broker if we are running under systemd because D-Bus * service activation won't work otherwise. */The following sample program, based on the at-spi-bus-launcher-code, could explain why the SSH case works: The "systemd, use dbus-broker" case is triggered for me on Debian testing in a KDE Plasma X11 session (and probably the same way for a Fedora 38 GNOME session), but not in an SSH session ("no systemd, don't use dbus-broker").
---------------------------------------------------
// build: g++ -o test test.cxx -lsystemd
#include <iostream>
#include <unistd.h>
#include <systemd/sd-login.h>
int main()
{
// s.
https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/e7310f8a57cf9d9744f68059fad451cb3acd116a/bus/at-spi-bus-launcher.c#L453-460
char* unit;
if (sd_pid_get_user_unit (getpid (), &unit) >= 0)
std::cout << "systemd, use dbus-broker" << std::endl;
else
std::cout << "no systemd, don't use dbus-broker" << std::endl;
}
---------------------------------------------------
What if we try `dbus-broker-launch` (assuming it's compatible) instead of `dbus-launch` if the former is available? Would that help?
As Stephan mentioned already, it's not compatible as a drop-in-replacement.Maybe this more complicated way mentioned in the Github discussion I mentioned earlier could work:
Question [2]:"What is the recommended way to run a nested dbus session, if not by using dbus-run-session? I mostly use it to run debug instances of GNOME Shell, as well as the for the CI pipeline when running inside Docker."
Answer (next comment): "We don't have a recommended way to do that. If that functionality is needed, it should be straightforward to achieve by just invoking your private instance of `dbus-broker-launch`. Socket-activation for the listener-socket is mandatory, though. So I would imagine creating `dbus-broker@.socket` and `dbus-broker@.service` as systemd template units, which take a path as template-argument where to place the socket. It should then be as simple as `systemctl start dbus-broker@foobar.service` to get it up and running. If, however, you intend to integrate it into a test-suite, I would rather expect the test-suite to create the listener manually and pass it through `execve(2)` to `dbus-broker-launch`."
I don't have any system to test this with yet, and it might take some time before I can have a F38 VM up and running with a LO build setup, but I'll try and see to this soon if it's a concern.
I'm on vacation this week, but could give this another try in my Fedora VM sometime afterwards. Or, if you're also attending LibreOffice conference next week in person, we could also take a look at it together then for example.
[1] https://gitlab.gnome.org/GNOME/at-spi2-core/-/blob/e7310f8a57cf9d9744f68059fad451cb3acd116a/bus/at-spi-bus-launcher.c#L453-460
[2] https://github.com/bus1/dbus-broker/issues/145#issuecomment-437874214
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
