Bug 404335

I am tempted to close this, and ask for a notification once Ubuntu LTS supported dbus-broker for at least two years.

The issue is not about that you should rely on dbus-broker but about that you shouldn't rely on dbus-daemon and be agnostic of whatever dbus implementation is used. In other words prepare for that dbus-run-session won't exist on system anymore. dbus-broker maintainers gave you same ideas what to do but it's also possible to just omit dbus-run-session command and run /usr/bin/startplasmacompositor directly.

I assume that at the time "Ubuntu LTS supported dbus-broker for at least two years" the vast majority of distros will already migrate to dbus-broker so unless the goal is to make KDE wayland session an Ubuntu LTS only thing you would better to reconsider this. Fedora 30 is expected in May 2019.

No, you don't have to thank me for this heads-up at all.

>but it's also possible to just omit dbus-run-session command and run /usr/bin/startplasmacompositor directly.

That's true only if one has dbus socket activated.

(In reply to David Edmundson from comment #3)
> That's true only if one has dbus socket activated.

Switching plasma session to run as systemd user service would allow to create dependency on dbus.socket service.

We absolutely cannot do that as a strict dependency.

(In reply to David Edmundson from comment #5)
> We absolutely cannot do that as a strict dependency.

Then don't and simply assume that system has dbus already started which is true for most if not all distros. The current approach is described as detrimental[1]

https://github.com/bus1/dbus-broker/issues/145#issuecomment-398727176

Yes, that's why this bug is still open.

That doesn't mean I'm just going to naively replace one bug for another.

Gnome 3.34 adopted systemd for start/manage session: https://blogs.gnome.org/benzea/2019/10/01/gnome-3-34-is-now-managed-using-systemd/

I hope KDE join it some day. I saw some effort in https://github.com/KDE/plasma-systemd-integration but it stalled.

I would like to point out that even with the regular D-Bus implementation using `dbus-run-session` causes problems. This is at least the case under systemd-based distributions where the D-Bus processes (including the session D-Bus) are started via systemd.

I've explained it in further detail in this Arch Linux issue: https://bugs.archlinux.org/task/66766

The main problem is that `org.freedesktop.systemd1` is not available this way preventing software relying on it to work, e.g. https://github.com/Martchus/syncthingtray#required-system-configuration.

In my opinion starting the session D-Bus and starting the graphical environment should not be coupled.

What might work is to have a wrapper around dbus-run-session which only starts a session bus if necessary, e.g.:

drs=
[ -n "${DBUS_SESSION_BUS_ADDRESS}" ] || drs=dbus-run-session
exec ${drs} "$@"

Maybe this could be added to startplasma-wayland itself.

What is unavoidable though is the use of dbus-run-session to start the bus if it's not there yet.
There's simply no alternative. That seems to be the consensus on https://github.com/bus1/dbus-broker/issues/145 as well.

>There's simply no alternative. That seems to be the consensus on https://github.com/bus1/dbus-broker/issues/145 as well.

Ack, but I've personally changed my mind about whether it's our responsibility to do any kind of fallback.
(https://phabricator.kde.org/D19004)

dbus-broker and dbus-daemon are both socket activated. On all good setups it will "just work". 
It was just a hack for an old Ubuntu at the time, but that's no longer the case.

(In reply to David Edmundson from comment #11)
> >There's simply no alternative. That seems to be the consensus on https://github.com/bus1/dbus-broker/issues/145 as well.
> 
> Ack, but I've personally changed my mind about whether it's our
> responsibility to do any kind of fallback.
> (https://phabricator.kde.org/D19004)
> 
> dbus-broker and dbus-daemon are both socket activated. On all good setups it
> will "just work". 
>
> It was just a hack for an old Ubuntu at the time, but that's no longer the
> case.

Unless on X11, where a property is changed on the root window, DBUS_SESSION_BUS_ADDRESS has to be set in the environment to have a common session bus. So unless DBus is explicitly started by a parent process in one way or another, this is actually not enough AFAICT.

With systemd, pam_systemd takes care of that I think, but what is on systems where this isn't the case, like without systemd or on FreeBSD, where DBus is an "afterthought"?

The method of only using dbus-run-session if DBUS_SESSION_BUS_ADDRESS is unset seems the safest.

Those setups don't get wayland anyway, but it's certainly the easiest path to resolving the bug, so I'll make an updated patch doing that.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/128

davidedmundson wrote:
> @bug_id = 404335
> @bug_status = RESOLVED
> @resolution = FIXED
> @cf_commitlink = https://invent.kde.org/plasma/plasma-workspace/commit/8475fe4545998c806704a45a7d912f777a11533f
>
> Git commit 8475fe4545998c806704a45a7d912f777a11533f by David Edmundson.
> Committed on 30/06/2020 at 10:59.
> Pushed by davidedmundson into branch 'master'.
>
> Only spawn dbus-run-session if there isn't a session already
>
> Typically on modern systems this will be started for us earlier in the
> startup series and we don't have to worry about it.
>
> For X11 clients look for the bus address on the X11 root window as a way
> of sharing.
>
> For reasons at the time we start our own DBus session within our wayland
> session. Nesting causes conflicts and problems so this patch only start
> a dbus session if one has not been set up already.
>
> M  +1    -1    login-sessions/plasmawayland-dev.desktop.cmake
> M  +1    -1    login-sessions/plasmawayland.desktop.cmake
> M  +1    -0    startkde/CMakeLists.txt
> A  +10   -0    startkde/plasma-dbus-run-session-if-needed

Thanks for the fix.

This fix causes a black screen desktop on Fedora 33 when using the combination of Radeon and SDDM.
It has been reported here:
https://github.com/sddm/sddm/issues/1335
and here:
https://bugzilla.redhat.com/show_bug.cgi?id=1897717

So we think DBus is started, but DBUS_SESSION_BUS_ADDRESS is not set?


If we're unsure, lets add some

echo HERE >> /tmp/log

type messages throughout that script

Thanks for the quick response.  Here is what was produced by the script:

dbus_session_bus_address unix:path=/run/user/1000/bus

OpenGL vendor string:                   X.Org
OpenGL renderer string:                 AMD PITCAIRN (DRM 2.50.0, 5.9.14-200.fc33.x86_64, LLVM 11.0.0)
OpenGL version string:                  4.5 (Core Profile) Mesa 20.2.4
OpenGL shading language version string: 4.50
Driver:                                 RadeonSI
GPU class:                              Southern Islands
OpenGL version:                         4.5
GLSL version:                           4.50
Mesa version:                           20.2.4
Linux kernel version:                   5.9.14
Requires strict binding:                no
GLSL shaders:                           yes
Texture NPOT support:                   yes
Virtual Machine:                        no
plasmalog.txt (END)

The results in the file are the same for both GDM and SDDM.  The difference is that GDM opens Plasma successfully.  SDDM opens the plasma session with a solid black screen.  I can open a terminal window, but the desktop is solid black, I can't see any panels.

that echo was before the if statement?

And commenting out 

"if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ]
then
    drs=dbus-run-session
fi"


magically makes things work?

(In reply to David Edmundson from comment #20)
> that echo was before the if statement?

Yes, I put that in to show the value.  It is still part of the if statement, but since it exists the if statement isn't triggered.

> 
> And commenting out 
> 
> "if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ]
> then
>     drs=dbus-run-session
> fi"
> 
> 
> magically makes things work?

I don't actually comment out that if statement, what I do was suggested here:
https://github.com/sddm/sddm/issues/1335

Which basically bypasses this script all together and just invokes dbus-run-session.

Interesting to note, the script works fine when running GDM, it's only when using SDDM that it is an issue - and apparently only when using radeon graphics.

Part of the problem too may be that fedora switched to using dbus-broker by default instead of dbus-daemon awhile back (and dbus-run-session is for the latter),
https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementation

Sorry, just realized that was mentioned first comment.

Anyone experiencing issues (Gerald?), try adding this near the top of
/usr/libexec/plasma-dbus-run-session-if-needed

# probe dbus first
qdbus-qt5 >& /dev/null ||:

(before the check: if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ] )

that will ensure socket activation has a chance to start it first

(In reply to Rex Dieter from comment #24)
> Anyone experiencing issues (Gerald?), try adding this near the top of
> /usr/libexec/plasma-dbus-run-session-if-needed
> 
> # probe dbus first
> qdbus-qt5 >& /dev/null ||:
> 
> (before the check: if [ -z "${DBUS_SESSION_BUS_ADDRESS}" ] )
> 
> that will ensure socket activation has a chance to start it first

Hey Rex, thanks for the suggestion.  Unfortunately it didn't work.  If you look at the script trace info I provided in comment #19, it shows:  
dbus_session_bus_address unix:path=/run/user/1000/bus 

As we're getting closer to F34, I would suggest we look at switching out SDDM for GDM unless we get some quick traction on getting this issue resolved.

Well I'm stumped, you're effectively unconditionally running dbus-daemon (to replace an already-running dbus-broker) and that somehow works.  Using dbus-broker doesn't work (for you).  We still have no idea why, and no clues why this only affects some users.  

Is that a fair assessment?

(In reply to Rex Dieter from comment #26)
> Well I'm stumped, you're effectively unconditionally running dbus-daemon (to
> replace an already-running dbus-broker) and that somehow works.  Using
> dbus-broker doesn't work (for you).  We still have no idea why, and no clues
> why this only affects some users.  
> 
> Is that a fair assessment?

We do know a little bit.  AFAIK it only affects Radeon users in conjunction with SDDM, or rather let's put it this way, I haven't heard of any reports with people using other chipsets.  It also started when the change in comment #15 was introduced.  The SDDM bug is referenced in comment #17.

Created attachment 134407 [details]
Beginning of wayland-errors

The symptoms of this issue are the following, right?
- The desktop background is black.
- There is no context menu on the background.
- The panel doesn't start.
- Applications started via autostart files DO get started.

If so; I see this issue too, but with Intel graphics. (More exactly, a Lenovo T460.) This is on Fedora 33. It didn't appear when I initially upgraded to 33, but when I recently upgraded everything it started.

I tried the suggestion from comment #24, but it didn't make any difference. I also added a ps command, and redirected standard out to standard error so it would get caught in the wayland-errors file, and attach the beginning of that file here. (I don't know where standard out shows up, if anywhere, otherwise.)

(In reply to Göran Uddeborg from comment #28)
> Created attachment 134407 [details]
> Beginning of wayland-errors
> 
> The symptoms of this issue are the following, right?
> - The desktop background is black.
> - There is no context menu on the background.
> - The panel doesn't start.
> - Applications started via autostart files DO get started.
> 
> If so; I see this issue too, but with Intel graphics. (More exactly, a
> Lenovo T460.) This is on Fedora 33. It didn't appear when I initially
> upgraded to 33, but when I recently upgraded everything it started.
> 
> I tried the suggestion from comment #24, but it didn't make any difference.
> I also added a ps command, and redirected standard out to standard error so
> it would get caught in the wayland-errors file, and attach the beginning of
> that file here. (I don't know where standard out shows up, if anywhere,
> otherwise.)

Yes, that's the issue.  Thanks for the report.  Have you tried using GDM?  For me at least, GDM appears to work fine - the problem only appears to manifest itself when using SDDM.

Yes, starting my (plasma) session from GDM everything seems to work properly.

can someone direct me to an ISO/Virtualbox Image which I can use to reproduce?

Here is a response from:  https://bugzilla.redhat.com/show_bug.cgi?id=1912046
In case you didn't see it.  

I pushed a pull request to beef up systemd's docs a bit: https://github.com/systemd/systemd/pull/18137.
It also deprecates a blanket 'systemctl import-environment' command and changes systemctl to emit
a warning when that is used.

It is fairly easy to describe how the environment is constructed by systemd, but the interaction
with other parts of the stack is complex and not documented well. I don't think the systemd
man pages are appropriate for this kind of documentation — we don't have the expertise and they
would become stale at some point. We could probably put a document under systemd.io if no better
place is found.

> To dig a bit further, the memo says "Define shell-specific setup through shell-specific profile scripts.",
> but systemd goes through the shell-specific profile scripts.

Systemd itself doesn't use the shell *at all*. This also means that it doesn't care about profile
scripts. Instead, various desktop environments execute in an environment where the shell profile
functions have been executed, and when they call 'import-environment' or the dbus-api equivalent
to propagate session-specific variables, various variables are pushed to the manager environment
block. I don't think this makes sense, because we end up with too many wrong things in the global
environment.

What I think should happen is that the desktop environment should export a few variables it
sets itself (emphasize *itself* here, if the desktop environment is assigning a variable, it knows
whether it belongs in the global session block): DESKTOP_SESSION, DISPLAY, GDMSESSION, GDM_LANG,
GNOME_SETUP_DISPLAY?, SESSION_MANAGER?, WAYLAND_DISPLAY, XAUTHORITY, XDG_SESSION_*, or equivalent
for other environments.

Whenever a shell process is created for the user, it should execute shell profile functions and
create set the shell-specific variables there.

I'm not an expert in bash profile initialization, but it seems that the right thing happens already:
when I clean up my systemd user environment block by removing e.g. all MODULE* variables, and
start a shell process as a service, I get them back:
$ systemd-run --user -t bash
(nested) $ set|grep ^MODULE
MODULEPATH=/etc/scl/modulefiles:/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefiles
MODULEPATH_modshare=/usr/share/modulefiles:1:/usr/share/Modules/modulefiles:1:/etc/modulefiles:1
MODULESHOME=/usr/share/Modules
MODULES_CMD=/usr/share/Modules/libexec/modulecmd.tcl
MODULES_RUN_QUARANTINE='LD_LIBRARY_PATH LD_PRELOAD'

When I start a gnome-terminal, the shell in the gnome terminal also has the MODULE* variables.
So it seems that the environment-modules stuff is properly initialized without pushing anything
through the manager environment block.
I don't think there's anything to fix in environment modules. It's gnome-desktop/kde that might
need some tweaking.

We changed some setting/unsetting env paths in 5.24 please retest

Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!

This bug has been in NEEDSINFO status with no change for at least
30 days. The bug is now closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!