Bug 1147651 - Wayland sessions do not set/get correct dbus session bus address
Wayland sessions do not set/get correct dbus session bus address
Status: RESOLVED FIXED
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: KDE Workspace (Plasma)
Current
x86-64 openSUSE Factory
: P5 - None : Normal (vote)
: ---
Assigned To: E-Mail List
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-08-24 21:46 UTC by Tejas Guruswamy
Modified: 2020-07-27 08:39 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tejas Guruswamy 2019-08-24 21:46:40 UTC
New Tumbleweed installation, verified under a blank new user.

Wayland (+Plasma) user sessions on my machine do not seem to set/get the right DBUS session bus address

> env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-mD80k1oNq5,guid=fa357084a326708efc6312165d61aa7e

whereas under X11, on console, and for services started by a systemd user session, the DBUS session bus address is

> systemctl --user show-environment | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
> env | grep DBUS
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

The consequence is that programs started under Wayland cannot connect to services started by the systemd user session, in particular pulseaudio.
pulseaudio-related applications like pulseaudio-dlna therefore do not work under Wayland (but do under X11).
Comment 1 Simon Lees 2019-08-27 09:42:58 UTC
I don't have an easy way of starting wayland atm so some help debugging would be useful, can you run "systemctl status user-1000.slice" under both wayland and x11 then give me the dbus service part. My initial suspicion is in this case the right paramaters are not being passed to dbus daemon on startup, this should help us verify if that is the case.
Comment 2 Tejas Guruswamy 2019-09-13 01:00:53 UTC
Under X11

> systemctl status user-1000.slice | grep dbus
     │ ├─ 6337 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only
Comment 3 Tejas Guruswamy 2019-09-13 01:03:18 UTC
And under Wayland

~> systemctl status user-1000.slice | grep dbus
           │ ├─ 883 /usr/lib/sddm/sddm-helper --socket /tmp/sddm-authde015e4c-3736-4de0-b6e9-622f475d4a77 --id 3 --start dbus-run-session /usr/bin/startplasmacompositor --user tejas
           │ ├─ 899 dbus-run-session /usr/bin/startplasmacompositor
           │ ├─ 918 dbus-daemon --nofork --print-address 4 --session
             ├─dbus.service
             │ ├─6337 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only

here it seems there are two dbus sessions started?
Comment 4 Tejas Guruswamy 2020-04-30 19:05:34 UTC
Just confirming this bug still exists on current TW.

kwayland-integration-5.18.4.1-1.1.x86_64
kwayland-5.69.0-1.1.x86_64
plasma5-session-wayland-5.18.4.1-1.1.noarch
libwayland-client0-1.18.0-1.2.x86_64
libwayland-server0-1.18.0-1.2.x86_64
systemd-245-3.1.x86_64

I suspect a 'Plasma (Wayland)' session is running Plasma under an extra 'dbus-run-session'.
Comment 5 Simon Lees 2020-05-01 00:14:52 UTC
(In reply to Tejas Guruswamy from comment #4)
> Just confirming this bug still exists on current TW.
> 
> kwayland-integration-5.18.4.1-1.1.x86_64
> kwayland-5.69.0-1.1.x86_64
> plasma5-session-wayland-5.18.4.1-1.1.noarch
> libwayland-client0-1.18.0-1.2.x86_64
> libwayland-server0-1.18.0-1.2.x86_64
> systemd-245-3.1.x86_64
> 
> I suspect a 'Plasma (Wayland)' session is running Plasma under an extra
> 'dbus-run-session'.

yeah this is likely the case, I don't use plasma, but I know enlightenment will start a dbus session if it can't find one already running, maybe Plasma is doing the same and failing to detect the other session or maybe it doesn't check for it. I'm not a Plasma expert so i'm not sure.
Comment 6 Fabian Vogt 2020-07-27 08:39:40 UTC
Got fixed upstream, will be part of Plasma 5.20: https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/128