Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 888523 - gui-wm/sway with sys-auth/elogind doesn't initialize DBUS_SESSION_BUS_ADDRESS properly
Summary: gui-wm/sway with sys-auth/elogind doesn't initialize DBUS_SESSION_BUS_ADDRESS...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Matthew Thode ( prometheanfire )
Depends on:
Reported: 2022-12-26 15:20 UTC by Esteve Varela Colominas
Modified: 2022-12-28 09:27 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Esteve Varela Colominas 2022-12-26 15:20:03 UTC
Not sure where to file this bug under, as it's not strictly a distro bug, but I'm (ab)using the bug tracker to explain the current situation and get guidance on who to best poke to improve this situation.

I've been running openrc+elogind+sddm+i3 for a while, and I've been looking to switch to sway. In doing so, I inmediately notice programs (primarily firejail) malfunctioning because they can't find the dbus daemon. It turns out, with the setup mentioned in the title DBUS_SESSION_BUS_ADDRESS isn't being set, at all.

In the traditional Xorg setup, /usr/share/sddm/scripts/Xsession is responsible for sourcing /etc/X11/xinit/xinitrc.d/80-dbus, which executes the appropriate dbus-launch command before running the window manager. However, in the equivalent /usr/share/sddm/scripts/wayland-session for wayland, no such thing is happening.

In search of what the proper initialization method is for dbus, I've looked into how other distributions handle sway:
- manjaro-sway/garuda-sway (systemd): greetd is the display manager, directly calls the "sway" binary. XDG_SESSION_BUS_ADDRESS ends up initialized.
- debian (systemd): just follows the command in /usr/share/wayland-sessions/sway.desktop, i.e. directly invoke "sway". XDG_SESSION_BUS_ADDRESS ends up initialized.
- artix (openrc): idem, XDG_SESSION_BUS_ADDRESS isn't set here, however.

It seems that the dbus variable is properly initialized in all the systemd distros, and I'm not sure how it's happening, after checking all the sway- and sddm-related files. Has the initialization been shoved off to logind?

Out of curiosity, I've tried KDE on wayland as well. This desktop seems to initialize the variable properly on every distro regardless of init system. After inspecting the /usr/share/wayland-sessions/plasmawayland.desktop file, it contains the following line:
    /usr/lib/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland
It seems that they've opted to *make sure* dbus is running under any circumstance.

After this research, I'm still left wondering: Where should the dbus initialization appear in gentoo to make sure the variable is set? I want to prod one of the parties to improve this situation, but I'm unsure if it should be introduced in:
- sddm: Have the wayland-session script read a directory similar to xinitrc.d, add a file to sys-apps/dbus to do it). Annoying because there's no standard for a directory like this, so we'd end up with a distro-specific situation.
- sway: Have the sway.desktop file do the same thing plasma does. I'm not sure a contribution like this would be accepted, however, as it limits user agency (sway users tend to dislike dbus), and doesn't affect users launching sway from a TTY.
- elogind: In the off chance that dbus is initialized in logind on systemd, maybe elogind should reflect this behavior?

I hope to be able to get some input on where to go with this.
Comment 1 Mike Gilbert gentoo-dev 2022-12-26 22:43:36 UTC
Under systemd, the session/user bus is started by systemd --user whenever a login session is started. This happens via a bus call from pam_systemd to logind.

The DBUS_SESSION_BUS_ADDRESS variable also gets set by the pam_systemd PAM module.

elogind has the same code to set DBUS_SESSION_BUS_ADDRESS in pam_elogind, but I don't think it provide a way to automatically start dbus-daemon for a session bus.
Comment 2 Esteve Varela Colominas 2022-12-27 22:08:16 UTC
I see. So in principle it wouldn't be necessary to `eval` the results of dbus-launch, as long as it's launched somehow before is invoked, and the bus appears in the right location? Neat.

It's interesting though, because the apps that are failing with the current setup fall back to checing $XDG_RUNTIME_DIR/bus if the variable isn't set, which is a completely valid operation. However, dbus-launch is currently always putting the socket in /tmp/dbus-XXXXXXXXXX. I wonder if systemd forces the new location, or if it's dbus itself that does this and it somehow isn't doing it downstream? Sounds like a separate issue...

So, yeah, since there's no equivalent to systemd --user that elogind can use, I guess this should be solved in either sway or sddm, possibly both.
Comment 3 Mike Gilbert gentoo-dev 2022-12-27 22:38:38 UTC
(In reply to Esteve Varela Colominas from comment #2)
> I wonder if systemd
> forces the new location, or if it's dbus itself that does this and it
> somehow isn't doing it downstream?

Just FYI, this happens in dbus.socket.

When this unit is started, systemd creates a socket at the path specified by ListenStream. The %t is replaced with $XDG_RUNTIME_DIR, which defaults to /run/user/$UID.

There's no equivalent functionality with OpenRC/elogind.
Comment 4 Piotr Karbowski archtester Gentoo Infrastructure gentoo-dev Security 2022-12-27 22:43:31 UTC
Looking though the code that Floppym linked and taking into account that pam_elogind runs on the login only, it checks for $XDG_RUNTIME_DIR/bus to set this variable, I do not think it will work at all, perhaps this codepath was never working in the first place in elogind.

The $XDG_RUNTIME_DIR for uid 1000 is /run/user/1000, and this directory is in fact created by pam_elogind upon login, it will not exist unless this is another *active* session of the same user.

I think you might want to take to elogind upstream and check if they are willing to introduce support for it given your valid use case given the elogind's premise of being logind's standalone implementation.

While not a solution to elogind not having feature parity with systemd-logind, you could try to change how sway is started. Instead of executing 'sway' have it run 'dbus-launch --exit-with-session sway' instead, exactly how the /etc/X11/xinit/xinitrc.d/80-dbus does it with $XSESSION. That should get you wayland session via sddm with $DBUS_SESSION_BUS_ADDRESS being set.

In this case, I think we could declare that the problem is that elogind is not systemd and falls short without rest of systemd's interfaces.