Bug 1817708 - KDE desktop session will not start when switching between users
Summary: KDE desktop session will not start when switching between users
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-desktop
Version: 32
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: KDE SIG
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: RejectedBlocker AcceptedFreezeExcepti...
Depends On: 1357426
Blocks: F32FinalFreezeException
TreeView+ depends on / blocked
 
Reported: 2020-03-26 19:18 UTC by Lukas Ruzicka
Modified: 2020-07-10 16:05 UTC (History)
25 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug


Attachments (Terms of Use)
The journal from the affected computer. (340.93 KB, text/plain)
2020-03-26 19:18 UTC, Lukas Ruzicka
no flags Details
Another journal of a similar situation. (397.33 KB, text/plain)
2020-03-27 17:52 UTC, Lukas Ruzicka
no flags Details
Kglobalaccel5 crashes in journal (1.31 MB, text/plain)
2020-04-02 10:14 UTC, Lukas Ruzicka
no flags Details
system journal for comment 10 (370.91 KB, text/plain)
2020-04-08 10:59 UTC, Kamil Páral
no flags Details
rpm -qa for comment 10 (55.86 KB, text/plain)
2020-04-08 11:00 UTC, Kamil Páral
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1781393 None None None 2020-04-08 11:27:49 UTC
Red Hat Bugzilla 1814678 None None None 2020-04-08 11:27:49 UTC

Description Lukas Ruzicka 2020-03-26 19:18:22 UTC
Created attachment 1673873 [details]
The journal from the affected computer.

Description of problem:

I installed KDE Live from the latest iso (20200325.n.0) and created several users. When I log in, the desktop environment will not start, I only see a black screen with a cursor. I can switch to another console and work normally there, so the machine itself is not stalled. This does happen quite regularly, but not always. 
I have only tested it in the VM, I can try testing it on bare metal tomorrow.

Version-Release number of selected component (if applicable):

How reproducible:
Regularly, but not always


Steps to Reproduce:
1. Install KDE Live.
2. Boot the system
3. Log in

Actual results:
See above

Expected results:

Desktop starts every time.

Additional info:
Journal attached. Possible reason:
===
Mar 26 20:07:22 localhost.localdomain systemd[978]: Starting Mark boot as successful...
Mar 26 20:07:22 localhost.localdomain systemd[978]: grub-boot-success.service: Succeeded.
Mar 26 20:07:22 localhost.localdomain systemd[978]: Started Mark boot as successful.
Mar 26 20:07:24 localhost.localdomain spice-vdagentd[1155]: Error getting active session: No data available
Mar 26 20:07:24 localhost.localdomain spice-vdagentd[1155]: Error getting active session: No data available
Mar 26 20:07:24 localhost.localdomain systemd[1]: Started Getty on tty2.
Mar 26 20:07:24 localhost.localdomain audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=getty@tty2 comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Mar 26 20:07:28 localhost.localdomain kernel: input: spice vdagent tablet as /devices/virtual/input/input7
Mar 26 20:07:28 localhost.localdomain spice-vdagentd[1155]: opening vdagent virtio channel
Mar 26 20:07:28 localhost.localdomain spice-vdagentd[1155]: Set max clipboard: 104857600
Mar 26 20:07:28 localhost.localdomain spice-vdagentd[1155]: Set max clipboard: 104857600
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Received Graphics Device Info:
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Device /dev/dri/card0 is at /sys/devices/pci0000:00/0000:00:01.0/drm/card0
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Found card '/sys/devices/pci0000:00/0000:00:01.0/drm/card0' with Vendor ID 0x100, Device ID 0x1b36
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Found matching X Output: name=Virtual-0 id=67
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Adding graphics device info: channel_id: 0 monitor_id: 0 device_address: pci/0000/01.0, device_display_id: 0 xrandr output ID: 67
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Unable to find a display id for output index 1)
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Unable to find a display id for output index 2)
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Unable to find a display id for output index 3)
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Received Graphics Device Info:
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Device /dev/dri/card0 is at /sys/devices/pci0000:00/0000:00:01.0/drm/card0
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Found card '/sys/devices/pci0000:00/0000:00:01.0/drm/card0' with Vendor ID 0x100, Device ID 0x1b36
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Found matching X Output: name=Virtual-0 id=67
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Adding graphics device info: channel_id: 0 monitor_id: 0 device_address: pci/0000/01.0, device_display_id: 0 xrandr output ID: 67
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Unable to find a display id for output index 1)
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Unable to find a display id for output index 2)
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: Unable to find a display id for output index 3)
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: vdagent_audio_playback_sync mute=no nchannels=2
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: vdagent-audio: (playback-left) 65535 (%99.00)
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: vdagent-audio: (playback-right) 65535 (%99.00)
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: vdagent_audio_record_sync mute=no nchannels=2
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: vdagent-audio: (capture-left) 65535 (%99.00)
Mar 26 20:07:28 localhost.localdomain spice-vdagent[2223]: vdagent-audio: (capture-right) 65535 (%99.00)
Mar 26 20:07:35 localhost.localdomain spice-vdagentd[1155]: closed vdagent virtio channel
Mar 26 20:08:15 localhost.localdomain systemd[978]: Started dbus-:1.2-org.kde.ActivityManager@1.service.
Mar 26 20:08:15 localhost.localdomain polkitd[773]: Registered Authentication Agent for unix-session:5 (system bus name :1.93 [/usr/libexec/kf5/polkit-kde-authentication-agent-1], object path /org/kde/PolicyKit1/AuthenticationAgent, locale en_US.UTF-8)
Mar 26 20:08:15 localhost.localdomain korgac[2228]: org.kde.pim.kidentitymanagement: IdentityManager: There was no default identity. Marking first one as default.
Mar 26 20:08:15 localhost.localdomain akonadi_control[2296]: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
===

Comment 1 Lukas Ruzicka 2020-03-27 17:51:44 UTC
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.

Comment 2 Lukas Ruzicka 2020-03-27 17:52:31 UTC
Created attachment 1674124 [details]
Another journal of a similar situation.

Comment 3 Fedora Blocker Bugs Application 2020-03-27 17:55:12 UTC
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.

Comment 4 Lukas Ruzicka 2020-03-30 15:43:05 UTC
The latest available compose - 20200228 - seems to be working ok, both on a bare meta and in VMs.

Comment 5 Geoffrey Marr 2020-03-30 19:15:39 UTC
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

Comment 6 Lukas Ruzicka 2020-04-02 10:12:33 UTC
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@0.service: Succeeded.
Apr  2 11:32:38 localhost systemd[945]: Started dbus-:1.2-org.kde.kglobalaccel@1.service.
Apr  2 11:32:38 localhost systemd[945]: dbus-:1.2-org.kde.KScreen@0.service: 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@0.service: Succeeded.
Apr  2 11:32:38 localhost systemd[945]: dbus-:1.2-org.kde.kglobalaccel@0.service: 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@1.service: 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@0-1805-0.service: Succeeded.
===

Comment 7 Lukas Ruzicka 2020-04-02 10:14:26 UTC
Created attachment 1675664 [details]
Kglobalaccel5 crashes in journal

Comment 8 Adam Williamson 2020-04-06 18:21:33 UTC
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?

Comment 9 Geoffrey Marr 2020-04-06 21:15:21 UTC
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

Comment 10 Kamil Páral 2020-04-08 10:59:08 UTC
(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.

Comment 11 Kamil Páral 2020-04-08 10:59:54 UTC
Created attachment 1677202 [details]
system journal for comment 10

Comment 12 Kamil Páral 2020-04-08 11:00:22 UTC
Created attachment 1677203 [details]
rpm -qa for comment 10

Comment 13 Kamil Páral 2020-04-08 11:13:31 UTC
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.)

Comment 14 Kamil Páral 2020-04-08 11:27:49 UTC
(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.

Comment 15 Mattia Verga 2020-04-08 14:49:58 UTC
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...

Comment 16 Rex Dieter 2020-04-08 15:47:32 UTC
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

Comment 17 Kamil Páral 2020-04-08 16:34:35 UTC
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.

Comment 18 Adam Williamson 2020-04-13 17:43:40 UTC
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.

Comment 19 Geoffrey Marr 2020-04-13 19:38:12 UTC
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

Comment 20 Marc Deop 2020-04-17 05:37:58 UTC
I thought it would be worth mentioning that I am using F31 and I am also experiencing this issue.

Comment 21 Chris Ross 2020-05-03 09:17:41 UTC
(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.

Comment 22 Rex Dieter 2020-05-19 22:24:12 UTC
We (KDE SIG) could also consider enabling the "KillUserProcesses=yes by default" feature for (only) kde spin releases in the future.

Comment 23 Andrey 2020-05-19 22:59:19 UTC
(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?

Comment 24 Edgar Hoch 2020-05-19 23:34:12 UTC
(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-* .)

Comment 25 Andrey 2020-07-09 23:04:24 UTC
(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?

Comment 26 Rex Dieter 2020-07-10 16:05:05 UTC
I'd imagine so, but I have no experience to draw on there (as I generally only use fedora/rhel)


Note You need to log in before you can comment on or make changes to this bug.