| Summary: | gui-wm/sway with sys-auth/elogind doesn't initialize DBUS_SESSION_BUS_ADDRESS properly | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Esteve Varela Colominas <esteve.varela> |
| Component: | Current packages | Assignee: | Matthew Thode ( prometheanfire ) <prometheanfire> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | asturm, floppym, kensington, slashbeast, speedjack95 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
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. https://github.com/systemd/systemd/blob/v252/src/login/pam_systemd.c#L284 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. https://github.com/elogind/elogind/blob/v251-pre/src/login/pam_elogind.c#L301 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 pam_elogind.so 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. (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. https://github.com/freedesktop/dbus/blob/dbus-1.14.4/bus/systemd-user/dbus.socket.in#L5 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. 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. |
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.