[question] What is equivalent of 'dbus-run-session' command?

[ghost]

Currently KDE plasma wayland session is started as Exec=dbus-run-session /usr/bin/startplasmacompositor . How to change it to use dbus-broker instead?

[dvdhrm]

There is currently no equivalent to dbus-run-session. The dbus-broker binary itself only implements the D-Bus Bus-logic, but not any surrounding environment. We provide dbus-broker-launch as a compatibility launcher for the user and system bus as described by the D-Bus spec. We do not provide launchers for other types of buses so far.

However, the launcher can be used for custom buses already (at-spi2 does that, for example). We want to be aware of these use-cases, though. So why exactly do you need dbus-run-session? Which distribution do you use? How do you start your graphical environment? Do you intentionally use a session bus rather than a user bus? Do you use any graphical greeter like gdm or kdm? Do you use systemd?

It is definitely possible to write something like dbus-run-session for dbus-broker, but I'd like not to, unless really necessary. So I first want to get a feeling why you use the tool, and maybe you can use some drop-in dbus-broker replacement already.

[ghost]

I'm using what upstream currently provides so it isn't config or distro dependent. I noticed that starting plasma-wayland session script directly without dbus like:
Exec=${CMAKE_INSTALL_FULL_BINDIR}/startplasmacompositor works however I don't know if there are any hidden consequences and I can't answer why KDE guys are starting the script like this.

[dvdhrm]

Perfect! Most distributions use systemd to start user and system buses these days. So the old session-bus-starter is obsolete. Back in the old days someone had to start the dbus session bus, so most desktop environments simply wrapped their start-up script in dbus-run-session. But if your distribution already manages the buses, it is even detrimental to use this, since you now might be unable to discover services that run on the other bus.

I am not sure what to do. I guess we should at least properly document this and recommend to everyone to drop the tool from their scripts.

[jadahl]

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.

[dvdhrm]

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 [email protected] and [email protected] 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 [email protected] 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.

[german-rios-gonzalez]

Hi @dvdhrm I used to use commands like this in my scripts:
sudo -u gdm dbus-run-session gsettings set org.gnome.settings-daemon.peripherals.keyboard numlock-state 'on'
I don't have the knowledge to understand what I need to do now in Fedora 30 where dbus-broker it's the default, I'm sorry for not elaborate better this sentences but english it'snt my mother language and thank you if you can guide me to find a solution

[dvdhrm]

To the best of my knowledge, this will still work on F30. The dbus-util package is still pulled in by dbus, IIRC, and dbus-util contains dbus-run-session.

[german-rios-gonzalez]

@dvdhrm thank you for your response, this guide me to found the command in the package dbus-daemon for now, I'll stay tuned to this thread if dbus-broker it's going to expose this functionality in the future, thanks again.

[dvdhrm]

Right, it remains in the dbus-daemon package, since we didn't want dbus-util to depend on the daemon package. Regardless, you can keep dbus-daemon installed just fine. The packages don't conflict, so if you want dbus-run-session working, you can always just keep the dbus-daemon package around and everything will be fine.

[Maryse47]

To the best of my knowledge, this will still work on F30. The dbus-util package is still pulled in by dbus, IIRC, and dbus-util contains dbus-run-session.

@dvdhrm
The problem with this is that it will spawn separate dbus user instance. In result there will be two of them running: one from dbus-broker and one from dbus-daemon. That sounds troublesome.

This issue was reported at KDE upstream but it seems they don't have ideas how to deal with it currently.

[dvdhrm]

@Maryse47 Errrr, dbus-run-session always starts a new session, regardless whether the original session is provided by dbus-daemon or dbus-broker. Same is true for dbus-launch. The only way to start a session conditionally based on whether there is one running already is dbus-launch --autostart. Did I get this wrong?

I am confused why so many people use dbus-run-session. I thought the idea was that login-systems or launchers use dbus-run-session to invoke the session, to make sure a dbus session is running. However, if a distribution uses systemd, this will inevitably lead to issues when systemd spawns a user bus as well, since then you end up with a system-bus, user-bus, and session-bus (or 2 session-buses, if an old systemd version is used which still spawns session-buses over user-buses).

I can understand why one would use dbus-launch --autostart, but that does not seem to be the case anywhere, right? So the only remaining use-case I see is to spawn temporary dbus sessions for development, testing, containers, etc. In those cases, I honestly think just sticking with dbus-run-session will be fine. I will gladly provide a replacement, if someone describes what the exact use-case is and we all agree on a way forward.

Maybe someone can enlighten me here? I must be missing something..
David

[jadahl]

FWIW, I use dbus-run-session in test suites to run tests requiring a session either in a nested dbus session, to let test applications own names normally owned by some other component in the DE, or in temporary sessions in CI where systemd isn't available.

[Maryse47]

@dvdhrm you have to ask kde folks. The current state where user ends up with running two different dbus implementations at the same time is not healthy.

[mcatanzaro]

So the only remaining use-case I see is to spawn temporary dbus sessions for development, testing, containers, etc.

I think that's indeed the exact use-case.

[Maryse47]

Here are the rationale for using this in KDE extracted from git history:

1. Launch dbus-session in wayland session (Appearantly this is required with some systems, where dbus user-session is not installed)
2. Use dbus-run-session instead of dbus-launch --exit-with-session (Summary: dbus-launch --exit-with-session behaves badly if there's no X server running. This resulted in it breaking when being launched from gdm or lightdm.)

[soloturn]

am using:

QT_QPA_PLATFORM=wayland XDG_SESSION_TYPE=wayland exec dbus-run-session gnome-session

on the command line, or in .bash_profile, to start GNOME, no GDM. as described here:
https://wiki.archlinux.org/index.php/GNOME#Wayland_sessions

shutdown, logout does not work anymore:

• within GNOME, using a terminal:

$ shutdown now
Failed to set wall message, ignoring: Connection timed out
Failed to power off system via logind: Connection timed out
Failed to talk to init daemon.

• from the panel, the shutdown button, or the logout button does not work anymore.

[mirage335]

If available, the "dbus-run-session" command, is used by the "Ubiquitous Bash" FakeHome 'virtualization' system, probably to further strip away any dependency on the user's own actual "$HOME" directory.
https://github.com/mirage335/ubiquitous_bash/blob/master/virtualization/fakehome/fakehome.sh#L158

In turn, this system is used by "webClient" to force web browsers (eg. FireFox, Chrome), filesystem browsers (eg. Dolphin), and similar programs to keep all files in subdirectories. In the future, other similar programs (eg. Arduino, gEDA/pcb2gcode), may be similarly contained.

Ultimately, 'dbus-run-session' may be a necessary workaround as part of a system to ensure programs may be configured independently of any global "$HOME" directory.

[azaghal]

@dvdhrm I have a similar use-case for the use of dbus-run-session command as @german-rios-gonzalez.

In my case this is for the Ansible (configuration management system) dconf module, which is just a wrapper around the dconf command. dconf is used to configure various applications (similar to the gsettings), and changes to configuration can be listened upon by the applications via D-Bus user session (so you can keep things in sync when changing configuration from the CLI).

Personally I use dconf to keep my desktop settings more easily synced across multiple machines. Now, while I am not a direct user of dbus-broker myself, a feature request/bug report got opened for the dconf Ansible module.

In case of Ansible, very often you will log-in (via SSH) with some pre-defined administrative account, and then switch to different users as necessary to run commands etc. While the initial login will result in a D-Bus user session getting set-up, the switch using e.g. sudo will not set-up a D-Bus session for the user one switches to.

Therefore, the dconf module will first try to locate a running D-Bus user session, and if that fails it'll simply wrap the command using the dbus-run-session command. I wanted to extend the dconf Ansible module to handle the dbus-broker implementation in similar manner, but then ran into same issue of not having an equivalent for the "standard implementation" command.

Given the existing example of gsettings, and the new one with dconf (which could be used in similar invocation manner as @german-rios-gonzalez gsettings example, not just via Ansible module), I would kinda disagree that the only use-cases are in development/testing/containers and similar. I've seen advice given to @german-rios-gonzalez to install/use the dbus-daemon package, but I would kinda expect that package will go away at some point simply because there's no need for it with dbus-broker being available.

[mcatanzaro]

I would kinda expect that package will go away at some point simply because there's no need for it with dbus-broker being available.

Don't worry, it's not going anywhere, because a ton of software depends on dbus-run-session. :P

[german-rios-gonzalez]

Don't worry, it's not going anywhere, because a ton of software depends on dbus-run-session. :P

Hi mister @mcatanzaro jokes aside, I am deeply concerned about the retirement at some point of the functionality of dbus-run-session I come from a developing country and I don't have the technical knowlegde to use other than methods than the recommended way to do the changes in gsettings for another users via gnome-terminal, may be it's just my zero knowledge about it, but with god as my witness I can't find in internet another way to do it, I use this method primary to change the behaviour of the GDM in a couple of laptops in a classroom and for change settings in the accounts for GNOME applications for some students that has special necessities, maybe itsn't «a ton of software depends on», but what it's the replacement for it that dbus-broker propose or there is something that GNOME project needs to figure out?
Mister @mcatanzaro please excuse me for my bad english isn't my native language if you could give some example how to use another method would be great

[mcatanzaro]

if you could give some example how to use another method would be great

Thing is, there really is no replacement for dbus-run-session: that's why this issue report exists.

Since dbus-run-session is used in tons of places, and there is no known alternative, I'm confident that dbus-daemon is going to stick around indefinitely, if only to provide this command. (At least until something else is written to replace dbus-run-session.)

[german-rios-gonzalez]

Thing is, there really is no replacement for dbus-run-session: that's why this issue report exists.

Since dbus-run-session is used in tons of places, and there is no known alternative, I'm confident that dbus-daemon is going to stick around indefinitely, if only to provide this command. (At least until something else is written to replace dbus-run-session.)

Hi mister @mcatanzaro thanks for the explanation, I understand better now what do mean in your first reply, and a special thanks for take the time to make it easy to understand, it's mean a lots to me, good sir

[mcatanzaro]

I can understand why one would use dbus-launch --autostart, but that does not seem to be the case anywhere, right? So the only remaining use-case I see is to spawn temporary dbus sessions for development, testing, containers, etc. In those cases, I honestly think just sticking with dbus-run-session will be fine. I will gladly provide a replacement, if someone describes what the exact use-case is and we all agree on a way forward.

Is this offer still valid? The use case is: use one simple command to start a D-Bus session in a CI environment (usually a container where it's very unlikely that systemd is running, if it exists at all).

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.

That's comparatively hard, though. When you're trying to provide bus access in a CI template, you don't want to be writing custom code.

[dvdhrm]

Is this offer still valid? The use case is: use one simple command to start a D-Bus session in a CI environment (usually a container where it's very unlikely that systemd is running, if it exists at all).

My question was: Why is dbus-run-session not suitable for that use-case?

[mcatanzaro]

My question was: Why is dbus-run-session not suitable for that use-case?

Well it is suitable for that, sure. (Unless you're specifically trying to run tests with dbus-broker.) But then we cannot ever get rid of dbus-daemon. I had assumed that the goal of dbus-broker was to obsolete dbus-daemon? It kinda seems like you've got 98% of the way, hit a small obstacle, and then gave up for no clear reason.

[dvdhrm]

But then we cannot ever get rid of dbus-daemon. I had assumed that the goal of dbus-broker was to obsolete dbus-daemon?

I personally don't want to get rid of dbus-daemon. The D-Bus team (and Smcv in particular) is doing a splendid job of keeping it inline with the specification, supporting niche targets, maintaining a test-infrastructure for the entire specification, and providing a reference implementation to anyone interested in writing servers. In particular the compatibility to historical oddities and peculiarities is not something we intend to replicate in dbus-broker.

I do appreciate not requiring dependencies to dbus-daemon on production systems, but I believe this is already the case.

It kinda seems like you've got 98% of the way, hit a small obstacle, and then gave up for no clear reason.

I don't believe this assessment reflects our efforts.

[seb128]

The lack of dbus-run-session is also somehow problematic for Ubuntu where from a desktop perspective we are trying to switch from dbus-daemon to dbus-broker by default.

The Ubuntu rules for promotion to the main component encourage to support only one solution to a problem, which means to have dbus-broker accepted we should moving dbus-daemon out of our default set.

gdm currently depends on dbus-run-session to start its greeter session as explained by their source comment
https://gitlab.gnome.org/GNOME/gdm/-/blob/main/daemon/gdm-session.c#L2973

[Conan-Kudo]

Can we please see a dbus-broker version of dbus-run-session? It's needed for being able to run D-Bus oriented applications in on-demand or containerized environments, and I'd rather use dbus-broker over dbus-daemon, given the better performance and integration.

[dvdhrm]

PR #321 provides a possible solution, for anyone interested.

[anonyco]

gdm currently depends on dbus-run-session to start its greeter session as explained by their source comment
https://gitlab.gnome.org/GNOME/gdm/-/blob/main/daemon/gdm-session.c#L2973

@seb128 Many thanks for your insights. Please remember to permalink URLs (where possible) so future viewers don’t get dead links:

https://gitlab.gnome.org/GNOME/gdm/-/blob/6184c8a9a113abc963452dd3fdc91d1597385f56/daemon/gdm-session.c#L2973

/* FIXME:
 * Always use a separate DBus bus for each greeter session.
 * Firstly, this means that if we run multiple greeter session
 * (which we really should not do, but have to currently), then
 * each one will get its own DBus session bus.
 * But, we also explicitly do this for seat0, because that way
 * it cannot make use of systemd to run the GNOME session. This
 * prevents the session lookup logic from getting confused.
 * This has a similar effect as passing --builtin to gnome-session.
 *
 * We really should not be doing this. But the fix is to use
 * separate dynamically created users and that requires some
 * major refactorings.
 */