KDE X11 should be started with dbus-run-session

[ProjectMoon]

System

• xuname: Void 5.4.39_1 x86_64 GenuineIntel uptodate rrFFFFFF
  output of xuname (part of xtools)
• package: plasma-workspace 5.18.5_1
  affected package(s) including the version

Expected behavior

When starting Plasma X11 session from SDDM (or another login manager, probably), tray icons and dbus notifications work properly. The DBUS_SESSION_BUS_ADDRESS environment variable should be defined.

Actual behavior

Tray icons do not work consistently, particularly for electron applications. dbus notifications from these applications are not received. DBUS_SESSION_BUS_ADDRESS is not defined.

Steps to reproduce the behavior

Log in with Plasma X11, start an electron app like Riot or Signal. No tray icon or notifications appear. At best, the taskbar icons will light up. Executing echo $DBUS_SESSION_BUS_ADDRESS or similar in the terminal will produce no result.

I fixed this by adding dbus-run-session at the front of the Exec= line of /usr/share/xsessions/plasma.desktop. This mimics the setup of /usr/share/wayland-sessions/plasmawayland.desktop, and makes the tray icon and notifications work again.

[ericonr]

So this happens even when launching Plasma from SDDM? The .desktop file seems to come from upstream, so we really shouldn't have any issues due to it.

https://community.kde.org/KWin/Wayland#Start_a_Plasma_session_on_Wayland makes it clear that plasma wayland requires dbus-run-session, I'm curious about X11, though. Might be worth a bug report upstream, I'm asking about it on #kde.

[ProjectMoon]

There have been similar reported issues with other login managers. See https://www.reddit.com/r/voidlinux/comments/f2vsjr/switching_to_kde_broke_discord_tray_notification/ for lightdm. There's something funny with KDE on X and dbus. But where the problem "truly lies," I am not sure.

Could be:

• Bug in upstream KDE
• Bug in upstream SDDM (and lightdm apparently)
• Bug somewhere in Void's configuration of these packages.

The only thing I know is that adding dbus-run-session fixes it for me.

[ericonr]

@Johnnynator have you ever had any issues with this?

I tried asking on IRC, got a resounding silence. Asking on r/kde might yield better results.

[furryfixer]

Probably not related? But you should be aware of this:
element-hq/element-web#12518

[ProjectMoon]

I've read it a few times before reporting this, but I don't think it's related. The tray icon works fine as long as KDE is running in a dbus session properly.

What I find odd is that KDE normally should just fail to start when it cannot connect to DBUS. It seems like it's something not getting passed down correctly maybe?

[furryfixer]

My knowledge is limited in this area, but I confirm this issue occurs with lxdm and xdm as well, so would not suspect DM's to be at fault. The issue does NOT occur at all with LXQT and same DMs.

Arch (or systemd specifically?) creates a dbus socket at "/run/user/$UID/bus" and assigns $DBUS_SESSION_BUS_ADDRESS to that socket. Void (elogind specifically?) does not (for any desktop environment I have installed).

In Void, at each login, both KDE and LXQT create a file in "~/.dbus/session-bus/" directory. This file contains a "$DBUS_SESSION_BUS_ADDRESS=unix:abstract=..." variable assignment for apps that want it. The comments indicate this can/will be used if "$DBUS_SESSION_BUS_ADDRESS is not otherwise set. It seems to be that, these electron apps at least, are not looking here. I assume because they always expect the bus address to be assigned (to the socket perhaps).

The difference between LXQT and KDE Plasma seems to be that LXQT actively assigns the value found in the file within "~/.dbus/session-bus/" directory to the $DBUS_SESSION_BUS_ADDRESS variable. This could perhaps be done somehow for the Void KDE Plasma package? Otherwise, Xsession scripts could use the method suggested above, "exec dbus-run-session @" for example, or "export $(dbus-launch)" prior to the exec line. Or, as we did when dbus stopped autolaunching X11 (before dbus-x11):

[ -z "$DBUS_SESSION_BUS_ADDRESS" ]  && eval `dbus-launch --sh-syntax`
export  DBUS_SESSION_BUS_ADDRESS
exec .....

[furryfixer]

I was too ignorant to realize the complex name of the dbus-session file is just the machine-id-0.
~/.dbus/session-bus/$(cat /var/lib/dbus/machine-id)-0. Since we know what the filename will be, we could simply (if KDE) source this file at login to set $DBUS_SESSION_BUS_ADDRESS. I leave it to maintainers to ponder whether this is a good idea, and if so, should it happen automatically or be manually done by the user within scripts in the ~/ directory.

[ericonr]

Per https://github.com/emersion/mako

If you are using elogind, you might need to manually start a dbus user session: dbus-daemon --session --address=unix:path=$XDG_RUNTIME_DIR/bus

Might be that upstream expects systemd-logind instead of elogind. We could patch the desktop file, I don't see any issues with doing so.

[Johnnynator]

I will add a patch with the next plasma release Johnnynator@3e1c65c

[furryfixer]

To be clear, I believe dbus-x11 starts a dbus-session already for Plasma (x11), but leaves the $DBUS_SESSION_BUS_ADDRESS unassigned? None-the-less, I see no downside to Johnnynator's patch.

[Johnnynator]

Fixed with the Plasma 5.19 updates.