More attempts to test KDE in the virtualized environment of OpenQA revealed that similar situation happens ALWAYS when switching users.

How to reproduce:

1. Log in as user A. Start an application.
2. Switch users.
3. Log in as user B. Start and stop an application.
4. Log out -> sddm will not come back, black screen happens, cursor shown, but machine can be controlled from the virtual console just fine.

Adding the journal again.

Created attachment 1674124 [details]
Another journal of a similar situation.

Proposed as a Blocker for 32-final by Fedora user lruzicka using the blocker tracking app because:

 I am proposing this as a blocker because it violates (at least) the following:

Shutdown, reboot, logout

Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops.

The latest available compose - 20200228 - seems to be working ok, both on a bare meta and in VMs.

Discussed during the 2020-03-30 2020-03-30 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as it would be good to have a few more folks try this out on different systems to confirm whether it's gone away.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-03-30/f32-blocker-review.2020-03-30-16.00.txt

So, in OpenQA, I am getting the same problem switching the users, even with the above mentioned compose, so this is clearly not working properly. I am adding the journal from the affected system, but the problem is probably related to kglobalaccel5 whose crash gets reported by Abrt when the user logs in, when they want to log out, the sddm screen will never come back and the system receives black screen.

===
Apr  2 11:32:38 localhost kscreen_backend_launcher[1299]: The X11 connection broke (error 1). Did the X11 server die?
Apr  2 11:32:38 localhost kglobalaccel5[1045]: The X11 connection broke (error 1). Did the X11 server die?
Apr  2 11:32:38 localhost kactivitymanagerd[1103]: The X11 connection broke (error 1). Did the X11 server die?
Apr  2 11:32:38 localhost kdeconnectd[1783]: The X11 connection broke (error 1). Did the X11 server die?
Apr  2 11:32:38 localhost systemd-logind[752]: Session 2 logged out. Waiting for processes to exit.
Apr  2 11:32:38 localhost kded5[1029]: QDBusAbstractAdaptor: Cannot relay signal KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
Apr  2 11:32:38 localhost kded5[1029]: QDBusAbstractAdaptor: Cannot relay signal KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
Apr  2 11:32:38 localhost kded5[1029]: QDBusAbstractAdaptor: Cannot relay signal KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
Apr  2 11:32:38 localhost kded5[1029]: QDBusAbstractAdaptor: Cannot relay signal KDEDModule::moduleDeleted(KDEDModule*): Pointers are not supported: KDEDModule*
Apr  2 11:32:38 localhost systemd[945]: dbus-:1.2-org.kde.ActivityManager: Succeeded.
Apr  2 11:32:38 localhost systemd[945]: Started dbus-:1.2-org.kde.kglobalaccel.
Apr  2 11:32:38 localhost systemd[945]: dbus-:1.2-org.kde.KScreen: Succeeded.
Apr  2 11:32:38 localhost kded5[1029]: The X11 connection broke: I/O error (code 1)
Apr  2 11:32:38 localhost systemd[945]: pulseaudio.service: Succeeded.
Apr  2 11:32:38 localhost systemd[945]: dbus-:1.2-org.kde.kdeconnect: Succeeded.
Apr  2 11:32:38 localhost systemd[945]: dbus-:1.2-org.kde.kglobalaccel: Succeeded.
Apr  2 11:32:38 localhost kglobalaccel5[1800]: qt.qpa.xcb: could not connect to display :0
Apr  2 11:32:38 localhost kglobalaccel5[1800]: qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
Apr  2 11:32:38 localhost kglobalaccel5[1800]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.#012#012Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.
Apr  2 11:32:38 localhost audit[1800]: ANOM_ABEND auid=1001 uid=1001 gid=1001 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=1800 comm="kglobalaccel5" exe="/usr/bin/kglobalaccel5" sig=6 res=1
Apr  2 11:32:38 localhost systemd[1]: Created slice system-systemd\x2dcoredump.slice.
Apr  2 11:32:38 localhost audit: BPF prog-id=39 op=LOAD
Apr  2 11:32:38 localhost audit: BPF prog-id=40 op=LOAD
Apr  2 11:32:38 localhost audit: BPF prog-id=41 op=LOAD
Apr  2 11:32:38 localhost systemd[1]: Started Process Core Dump (PID 1805/UID 0).
Apr  2 11:32:38 localhost audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@0-1805-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr  2 11:32:39 localhost systemd[945]: dbus-:1.2-org.kde.kglobalaccel: Succeeded.
Apr  2 11:32:39 localhost systemd-coredump[1806]: Process 1800 (kglobalaccel5) of user 1001 dumped core.#012#012Stack trace of thread 1800:#012#0  0x00007fdcf50a2a35 raise (libc.so.6 + 0x3ca35)#012#1  0x00007fdcf508b895 abort (libc.so.6 + 0x25895)#012#2  0x00007fdcf54aca25 _ZNK14QMessageLogger5fatalEPKcz (libQt5Core.so.5 + 0x8aa25)#012#3  0x00007fdcf5a1b06c _ZN22QGuiApplicationPrivate25createPlatformIntegrationEv (libQt5Gui.so.5 + 0x10806c)#012#4  0x00007fdcf5a1b698 _ZN22QGuiApplicationPrivate21createEventDispatcherEv (libQt5Gui.so.5 + 0x108698)#012#5  0x00007fdcf5671bf9 _ZN23QCoreApplicationPrivate4initEv (libQt5Core.so.5 + 0x24fbf9)#012#6  0x00007fdcf5a1d0c8 _ZN22QGuiApplicationPrivate4initEv (libQt5Gui.so.5 + 0x10a0c8)#012#7  0x00007fdcf5a1ddc8 _ZN15QGuiApplicationC2ERiPPci (libQt5Gui.so.5 + 0x10adc8)#012#8  0x0000556142cd7481 main (kglobalaccel5 + 0x2481)#012#9  0x00007fdcf508d042 __libc_start_main (libc.so.6 + 0x27042)#012#10 0x0000556142cd77de _start (kglobalaccel5 + 0x27de)
Apr  2 11:32:39 localhost audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=systemd-coredump@0-1805-0 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Apr  2 11:32:39 localhost systemd[1]: systemd-coredump: Succeeded.
===

Created attachment 1675664 [details]
Kglobalaccel5 crashes in journal

Lukas: from the log it looks like coredumpctl and abrt are both capturing those crashes. Can you use one of them to get a traceback?

Discussed during the 2020-04-06 blocker review meeting: [0]

The decision to delay the classification of this as a blocker bug was made as this could be a serious problem, but so far it only seems to reliably affect an openQA environment. We will send out a call for testing to see if many people hit this bug in 'real world' environments.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-04-06/f32-blocker-review.2020-04-06-16.00.txt

(In reply to Lukas Ruzicka from comment #1)
> How to reproduce:
> 
> 1. Log in as user A. Start an application.
> 2. Switch users.
> 3. Log in as user B. Start and stop an application.
> 4. Log out -> sddm will not come back, black screen happens, cursor shown,
> but machine can be controlled from the virtual console just fine.

I couldn't reproduce it with these exact steps. But I can completely reliably reproduce a black screen with these steps:

1. Log in as user A. Start an application.
2. Switch users.
3. Log in as user B. Start and stop an application.
4. Log out
5. In SDDM, select Switch users.
6. Try to log in as user B again. The login screen changes to a black screen with a cursor and nothing happens. A regular user can't escape from this screen.

You can use Ctrl+Alt+Fx to switch to different VTs, the system is not frozen. When you try to reboot, the system will hang for 90 seconds waiting for user B session to be terminated.

During step 6, the journal (among other things) shows these errors:

Apr 08 12:49:03 localhost.localdomain kaccess[2826]: Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.")
Apr 08 12:49:03 localhost.localdomain kded5[2807]: Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.")
Apr 08 12:49:03 localhost.localdomain ksmserver[2855]: Couldn't start kglobalaccel from org.kde.kglobalaccel.service: QDBusError("org.freedesktop.DBus.Error.NoReply", "Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.")

This was tested in a VM with Fedora-KDE-Live-x86_64-32-20200407.n.0.iso installed.

Created attachment 1677202 [details]
system journal for comment 10

Created attachment 1677203 [details]
rpm -qa for comment 10

Actually, here is an even simpler totally reliably reproducer™:

1. Log in as user A. Start an application.
2. Switch users.
3. Try to log back as user A (simply type in the password in SDDM). You should be back at your existing desktop, but instead you get a black screen (after short session starting animation) with no escape.

I have also tested this on a bare metal machine. Exactly the same behavior. (There is just a cosmetic difference - on bare metal, I see the session starting animation freeze, instead of changing to a pure black screen as in VM.)

(In reply to Adam Williamson from comment #8)
> Lukas: from the log it looks like coredumpctl and abrt are both capturing
> those crashes. Can you use one of them to get a traceback?

I saw two different crashes in abrt and tried to report both, they were already reported before. See bug 1814678 and bug 1781393.

I can reproduce this with steps in comment #13 also with Rawhide.
I noticed that in step nr 3 (when you log back as user A) the system tries to start a new session in VT2 instead of log back the user in the existent session on VT1...

re: comment #10 
plasma has historically been sensitive to lingering processes of previous sessions, particularly if you try logging in soon (within minutes) of a previous login.  I've typically advised users to do the following to mitigate that:
edit /etc/systemd/logind.conf to set
KillUserProcesses=yes

I tried waiting over 2 minutes between steps 2 and 3 in comment 13, no change.
I tried waiting over 2 minutes between steps 4 and 5 in comment 10, the problem doesn't occur, a new session for user B starts correctly.

So yes, the problem in comment 10 seems to be related to lingering processes after logout (and therefore might not be related to kglobalaccel crash). Perhaps it's time to separate all these issues into specific bug reports? Originally I thought it was the same problem, just different reproduction steps, but it no longer seems to be the case.

So we discussed this at blocker meeting today and rejected it. Geoff will do the formal update, but here's more info on the context.

Firstly, let's define "user switching": it's having multiple desktop user sessions active at the same time and switching between them, as opposed to logging in as 'user 1' then logging out and logging in as 'user 2' then logging out and back in as 'user 1' again or 'user 3' etc. If you log out every time it's not "user switching".

Back in January 2015 we were considering a GNOME user switch bug:

https://bugzilla.redhat.com/show_bug.cgi?id=1184933

we actually accepted it as a blocker, but agreed that user switching should be specifically listed in the criteria for the future and kparal took responsibility for that:

https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-01-26/f22-blocker-review.2015-01-26-17.00.html
https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2015-01-26/f22-blocker-review.2015-01-26-17.00.log.html

he started a thread on test@, kde@ and desktop@:

https://lists.fedoraproject.org/pipermail/test/2015-January/124811.html
https://lists.fedoraproject.org/pipermail/kde/2015-January/014175.html
https://lists.fedoraproject.org/pipermail/desktop/2015-January/011558.html

there was quite a lot of discussion, with camps both in favour of (mcatanzaro, kevin kofler...) and opposed to (mclasen, rdieter, josh boyer...) blocking on user switching. It seems like the discussion sort of petered out with no definite decision for or against being made, but the proposed criterion change was never made, which to me is more in line with user switching *not* being release blocking - we did not generate a sufficient consensus that it explicitly should be release blocking. This is the basis on which we rejected this bug as a blocker.

I can't find any later discussion on this - January 2015 seems to have been the last time we specifically considered it.

Discussed during the 2020-04-13 blocker review meeting: [0]

The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made, as in 2015 we accepted a GNOME user switch bug as a blocker and proposed a criteria change to explicitly cover it, but rdieter opposed the proposal and it never actually happened; on that basis we can't really accept this as a blocker but do accept it as FE

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-04-13/f32-blocker-review.2020-04-13-16.04.txt

I thought it would be worth mentioning that I am using F31 and I am also experiencing this issue.

(In reply to Marc Deop from comment #20)
> I thought it would be worth mentioning that I am using F31 and I am also
> experiencing this issue.

I second this, we get the same behaviour on Fedora 31 here.

We (KDE SIG) could also consider enabling the "KillUserProcesses=yes by default" feature for (only) kde spin releases in the future.

(In reply to Rex Dieter from comment #22)
> We (KDE SIG) could also consider enabling the "KillUserProcesses=yes by
> default" feature for (only) kde spin releases in the future.

Could someone explain what is drawback of this for other spins?

(In reply to Rex Dieter from comment #22)
> We (KDE SIG) could also consider enabling the "KillUserProcesses=yes by
> default" feature for (only) kde spin releases in the future.

Please note that a solution for only a spin is not a good solution. I think the concept of "spins" works only for single user systems, like a pc at home. For example, at a university we have to support multiple desktops on the same host with multiple languages, because staff and students came from different countries, speek different (native) languages and prefer different desktops, editors, programming languages, etc. So I always exclude all fedora-release-* packages and all *-environment groups, because I need a system that fits for everything, not only for server, desktop, gnome, kde, lxde, xfce, cinnamon, or any of the "labs" spins.

So I just install nearly all available desktops, but I some packages are not compatible with others, for example xscreensaver-extras, xscreensaver-extras, dnfdragora*, mate-applet-softupd, because the start even on desktops they are not designed for and conflict the the desktop's own tools (for example, two running screensaver steel each other the unlock password). I also install different programming languages, editors, databases, network services, etc., so each user can choose the environment and application he / she wants or needs, and it should work.

I understand a "spin" a list of packages that are needed and useful for a special environment or application tasks. And they are provided in a simple way to install (as an iso image). It should be nothing more. But currently the "spins" are not compatibles to each other because the spins contains packages that exclude packages of other spins (package fedora-release-*). But all "spins" should be installable in on host all together at the same time, meaning that the functionality of each spin can be used together at the same time, no need for different installations for each task. And in a multiuser environment, each user should be able to choose his / her preferred environment.

(I know this is the wrong forum to vote against spins, but I think anyway desktop environments should not only work when installed by the spin, but also when installed all neccessary packages (excluding paackages like fedora-release-* .)

(In reply to Rex Dieter from comment #16)
> re: comment #10 
> plasma has historically been sensitive to lingering processes of previous
> sessions, particularly if you try logging in soon (within minutes) of a
> previous login.  I've typically advised users to do the following to
> mitigate that:
> edit /etc/systemd/logind.conf to set
> KillUserProcesses=yes

Does it mean other systemd-based distros should be suffered also?

I'd imagine so, but I have no experience to draw on there (as I generally only use fedora/rhel)

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

we have later bugs in this general area tracking current status, so I don't think this needs re-opening, though we have seen similar issues.