Description of problem: On F34 KDE, I found a problem with logging out, after the "user switch" option has been used (even when no user has been actually switched). The outcome is that the user is switched to console - either to tty2 with a working text login prompt, or to tty1 where only a blinking cursor appears (no login prompt). In all cases, if the user is no power user, they'll have no idea what to do or how to even reboot the system safely. I found several different scenarios how to cause the problem, but I decided to report all of them into this single bug, because I believe the root cause is probably the same for all of them, it's just triggered differently. The first scenario can easily occur when you misclick a button (choose Switch User instead of Log Out). The second and third scenario can easily occur when user1 lets user2 to use the computer for a short while (like checking her email). Please see below the attached videos, reproduction steps, and logs. In all those scenarios, I see a suspicious error in the journal: > sddm[858]: Failed to read display number from pipe > sddm[858]: Could not start Display server on vt 2 Version-Release number of selected component (if applicable): Fedora-KDE-Live-x86_64-34-20210215.n.0.iso sddm-0.19.0-7.fc34.x86_64 plasma-workspace-5.21.0-1.fc34.x86_64 kf5-plasma-5.79.0-2.fc34.x86_64 dbus-1.12.20-3.fc34.x86_64 dbus-broker-26-2.fc34.x86_64 systemd-247.3-1.fc34.x86_64 kernel-5.11.0-0.rc7.149.fc34.x86_64 How reproducible: always Steps to Reproduce: will be provided for each use case individually, see comments below
Created attachment 1757527 [details] Scenario 1 video Scenario 1) A single user switch and logout 1. Log in using user1 2. KDE menu -> Leave -> Switch User 3. Log in back to the user1 session (don't switch the user) 4. KDE menu -> Leave -> Log Out -> OK 5. You'll end up on tty2 with a text login prompt. On tty3-tty6 there are also text login prompts. On tty1 there is only a blinking cursor. Sddm is nowhere to be found. See the attached video in this comment, and logs below.
Created attachment 1757528 [details] Scenario 1 journal
Created attachment 1757529 [details] Scenario 1 journal - priority notice and higher
Created attachment 1757530 [details] Scenario 2 video Scenario 2) Two users switch, the first logout fails 1. Log in using user1 2. KDE menu -> Leave -> Switch User 3. Switch User 4. Log in using user2 5. KDE menu -> Leave -> Log Out -> OK # there seems to be a race which will determine whether Scenario 2) or 3) will happen 6. You'll end up on some tty (perhaps tty4) with just a text blinking cursor. If you're a power user and know how to use Ctrl+Alt+Fn, you might be able to find a running sddm on a different tty. See the attached video in this comment, and logs below.
Created attachment 1757531 [details] Scenario 2 journal
Created attachment 1757532 [details] Scenario 2 journal - priority notice and higher
Created attachment 1757533 [details] Scenario 3 video Scenario 3) Two users switch, the second logout fails 1. Log in using user1 2. KDE menu -> Leave -> Switch User 3. Switch User 4. Log in using user2 5. KDE menu -> Leave -> Log Out -> OK # there seems to be a race which will determine whether Scenario 2) or 3) will happen 6. Return into the existing session of user1 7. KDE menu -> Leave -> Log Out -> OK 8. You'll end up on tty2 with a text login prompt. On tty3-tty6 there are also text login prompts. On tty1 there is only a blinking cursor. Sddm is nowhere to be found. (Alternatively, I've also seen ending up on just a black screen, with no login prompt, and VT switching not working). See the attached video in this comment, and logs below.
Created attachment 1757534 [details] Scenario 3 journal
Created attachment 1757535 [details] Scenario 3 journal - priority notice and higher
Created attachment 1757536 [details] rpm -qa
I nominate this to be a F34 Final blocker. It is somewhere in between these two criteria: "Shutting down, rebooting, logging in and logging out must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. " https://fedoraproject.org/wiki/Fedora_34_Beta_Release_Criteria#Shutdown.2C_reboot.2C_login.2C_logout "User switching must work using the mechanisms offered (if any) by all release-blocking desktops in their default configuration. " https://fedoraproject.org/wiki/Fedora_34_Final_Release_Criteria#User_switching Login/logout works, as long as you don't attempt to switch. Switching works, as long as you don't attempt to log out... :-)
Discussed during the 2021-02-22 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criteria: "Shutting down, rebooting, logging in and logging out must work..." and "User switching must work using the mechanisms offered...". It seems reasonable to expect both to work together. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2021-02-22/f34-blocker-review.2021-02-22-17.07.txt
Martin, Rex - where are we with this? This is an accepted F34 Final blocker, and Final freeze is coming up April 6. I'd like us to be out in front of accepted blockers at this point. Thanks!
I just tried to reproduce this bug here on my F34kde and it all worked fine, no bug. Will attach my output of rpm -qa to this ticket. Tried only in X11 sessions so far, will test on wayland later. Tested the scenarios with two users, firts is mine default user (adm) and second I created as regular user. Fedora 34 (KDE Plasma Prerelease) x86_64 / Kernel: 5.11.10-300.fc34.x86_64 / Plasma 5.21.3 / Qt: 5.15.2 / Frameworks: 5.80.0 sddm-0.19.0-8.fc34.x86_64 / sddm-breeze-5.21.3-1.fc34.noarch / sddm-kcm-5.21.3-1.fc34.x86_64 I'm ready to send more info if needed. :)
Created attachment 1767441 [details] rpm -qa from today
Tried on plasma wayland sessions... first and second time I log in and log out worked fine, but when I tried to switch users it didn't. SDDM freezed so badly that my only way out was a restart. then I tried several more times (6 to be honest) and it worked on 4 and had problems on 2 of them, but without the terrible freeze I experienced before. So, it apears this bug show itself when we use plasma wayland sessions.
Created attachment 1767460 [details] coredumpctl from plasma wayland attempt
Created attachment 1767462 [details] drkonki kcrash report
Forgot to say: I tested with two monitors (laptop and second monitor)
bug filed upstream, https://bugs.kde.org/show_bug.cgi?id=435389
Plasma upstream confirmed issue. The switch to systemd user sessions (and wayland) improvied some things (lingering processes on logout in particular), but seems we still have some steps to go. As upstream has documented this now as a known unresolved issue, https://community.kde.org/Plasma/Wayland_Showstoppers#Session_management I think there's not much we can do but live with it for now.
In chat, Nate Graham said they hope to have a fix by early next week. As a backup plan, we could consider disabling user switching in our sddm package until this is fixed.
https://koji.fedoraproject.org/koji/taskinfo?taskID=65861107 is a scratch build with the commit mentioned by Nate backported. If folks could please test that and see if it helps, that would be great. I'll try to follow kparal's reproducer steps myself today if I get a minute.
With scenario 1 and Adam's scratch build, I don't get the bad behavior in step 5. However logging back into the same user's session (step 3) gives me a black screen indefinitely. Once I switch to a different virtual terminal and back, I get a normal login session. With scenario 2/3 and Adam's scratch build, I can reliably switch between the two accounts. However, when logging out of one of those sessions, I get a black screen until I switch to tty-not1 and back to tty1. I'd say this patch improves things, but doesn't fully fix it. Scenario 1 seems less likely to be encountered in the wild than scenario 2/3 (though it's certainly something a general user might do). For the purposes of release blocking, I'd be willing to accept the scratch build as a sufficient fix for blocker status and commonbugs the remaining issues, with the hopes that we can fix it relatively soon after release.
Agree with Ben's remarks. Tested Adam's scratch build here too. Worked fine at X11, no errors. At wayland it worked changing users for 5 times, then when I logged out second user and tried to go to first user it gave me black screen, but with ctrl+alt+F1 the screen appeared again and worked fine. Scenario 2/3 returned just like Ben described.
FEDORA-2021-87d6b51834 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-87d6b51834
Thanks for the feedback, Ben and Geraldo. If it's not too much trouble it'd be great if you could re-test with the final update, as it's a bit different to the scratch build. It adds one more commit that we hope may improve things more (but it'd be good to know it at least doesn't make anything worse!) Thanks!
I tested with packages only from stable repos (updates-testing not used), and sddm updated to sddm-0.19.0-10.fc34. Scenario 1 from comment 1 is broken, but different. After step 3 I see only a black screen with a cursor. It seems 100% repeatable. I can use Ctrl+Alt+F1 to switch to the actual session. Scenario 2 from comment 4 is broken, basically unchanged. The only difference is that in step 6 I sometimes see a blinking cursor and sometimes just a black screen. It seems 100% repeatable. Ctrl+Alt+F1 can be used to switch to the first session. Scenario 3 from comment 7 I couldn't replicate (every time I tried, I got Scenario 2 instead). I also tested the scratch build from comment 23 and my results are exactly the same as above. So I'm not sure why it works better for other people, but there's little change (or even a regression) for me.
Created attachment 1771857 [details] Scenario 1 journal (sddm-0.19.0-10.fc34) I tested with a clean KDE VM installed from netinst with only stable repos enabled (and then sddm updated), still the same issue as in my comment above. Journal attached.
Created attachment 1771858 [details] Scenario 1 journal - priority notice and higher (sddm-0.19.0-10.fc34)
With sddm-0.19.0-10.fc34 (on Wayland), I get the same behavior as the scratch build. Improvement, but not a full fix. Like Kamil, it's always scenario 2 in the 2/3 test.
FEDORA-2021-87d6b51834 has been pushed to the Fedora 34 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-87d6b51834` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-87d6b51834 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Tested now with the new update (sddm-0.19.0-10.fc34). X11 sessions always works fine. Wayland sessions don't. Between scenarios 2/3 always gave me scenario 2. It doesn't goes to blank screen, but a freezed login screen, where I cannot click on nothing, but using ctrl+alt+F1 or F4 returns to the graphical session alright. So, I confirm here what Kamil and Ben found on their tests too.
I've made a scratch build[1] that adds one small extra commit[2] that may have an impact on this. Could folks test this and see if it helps any? [1]: https://koji.fedoraproject.org/koji/taskinfo?taskID=66095690 [2]: https://github.com/sddm/sddm/commit/8b371572ab6cf5f4652b7f95c700b13a89c9f109
With Wayland... The extra commit seems to make it slightly differently broken. Scenario 1 is unchanged. Scenario 2/3 results in: * if I log out user2, user1 gets the same "blank screen until I go back to tty1" behavior * if I log out user1, user2 gets an "x"-shaped cursor on a black screen and has to try Ctrl+Alt+F<N> until they find the correct tty I will note that switching between users (without logging out) seems to work fine. With X11... Scenario 1 works, except I have to enter the password twice. Scenario 2/3 results in what appears to be all ttys being blank, with the exception of a static cursor. But that may just be the system going catatonic, as it does not reply to ctrl+alt+del or libvirt's reboot and power off buttons. I have to force it off to recover. After downgrading to sddm-0.19.0.10 (FEDORA-2021-87d6b51834) I get the same behavior. (I had not previously tested X11)
I have the same results as Ben in my test environments with -10 and -11 on both X11 and Wayland. I had hoped that -11 would improve things, but nope. :(
Created attachment 1772703 [details] Crash coredump when doing Scenario 1 (sddm-0.19.0-11.fc34) At some point while having gdb attached to sddm while executing Scenario 1, I captured this coredump. It may or may not be useful, but might as well upload for posterity.
I also found a related issue from SDDM upstream on this that seems to describe some aspects of what we're seeing here: https://github.com/sddm/sddm/issues/1281
I looked into the possibility of disabling user switching, but I'm guessing this solution may not be agreeable either. Following https://develop.kde.org/deploy/kiosk/introduction/ I tested disabling combinations of action/switch_user action/start_new_session The result was that the menu options to do these were still present, clicking them effectively does nothing. If that's really the way we want to go, I can implement that to satisfy this blocker.
I think I'd prefer a button that does nothing to a button that drops people to a blank screen. I suspect a lot of more casual users would not know how to ctrl+alt+Fn their way back to a working session. We can commonbugs the Button That Does Nothing[tm] (and maybe put it in the release notes. I'd have to think about how to phrase that in the least "sorry we broke this for you, but it's better than the breakage you'd have otherwise" way). It doesn't seem like we're close to a real fix, so at this point I'd say nothing is better than something. I'm open to other arguments.
Given that we as a SIG haven't *actually* explicitly worked to support this functionality and my own failure to integrate upstream changes that *might* help here, I think we should go with the "buttons do nothing, CommonBugs to say why" approach. We can always go back and fix this with an update along with Plasma 5.22 in the summer.
To be clear, my recommendation is to modify https://bodhi.fedoraproject.org/updates/FEDORA-2021-87d6b51834 to *also* include the disabler as described in comment 39.
And once this is fixed upstream and pulled into an update, we should probably modify our OpenQA tests to add fast-user-switching cases so it doesn't break again in the future.
I think I would say that a button which does nothing would still be a blocker, as you'd be offering it and it clearly wouldn't work. *But*, we could reasonably waive it on the grounds that we can't say we have an opportunity to fix it properly in any kind of reasonable timeframe right now.
Is it really complicated to just patch out a menu button, though?
user switching is intentionally disabled for KDE in the openQA tests right now because it was known unreliable when we wrote them, btw: https://pagure.io/fedora-qa/os-autoinst-distri-fedora/blob/master/f/tests/desktop_login.pm#_274
(In reply to Adam Williamson from comment #45) > Is it really complicated to just patch out a menu button, though? I'd defer to Rex on this, but we'd need to patch out both kscreenlocker and sddm to get rid of the buttons. The UIs are duplicated in both programs.
I've been looking at it all morning. KDE appears to be locked in a heated battle with DNF for the title of Most Confusing Heap Of Abstraction Layers, but I'm trying a few ways to attack it.
Rex, are you sure you tested right? For me, with this in /etc/xdg/system.kdeglobals: [KDE Action Restrictions] action/switch_user=false action/start_new_session=false the entries disappear entirely from both the "Leave..." submenu and the lock screen, and that's what I *think* I'd expect from the code too.
Adam, I'll test again... possible I didn't restart my session after adjusting kdeglobals. You may be right, if so, we have a winner.
FEDORA-2021-a526beb5e7 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-a526beb5e7
Confirmed FEDORA-2021-a526beb5e7 removes the switch user button from the Leave menu and the lock screen.
Also can confirm the button is gone
Tested with Fedora 34 RC1. Confirmed the switch user button is gone.
Confirmed here too, with Fedora-KDE-Live-x86_64-34-1.1.iso no more user switching
FEDORA-2021-a526beb5e7 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
When is this being fixed? Taking user switching away from KDE desktop installs of Fedora 34 is not a solution, it is hiding a problem that has existed for more than a year. This challenge has been around since Fedora 32. You can't simply take user switching away from desktop machines, you are making KDE simply an unusable desktop.
Hi John, hopefully in F35, but it's really an upstream KDE issue, you need to ask there. User switching wasn't present in F33 either, btw. We have certain quality standards which must be met, which includes highly visible system actions to be working. If you want to experiment or you don't mind your sessions breaking, you can edit the file from comment 49 and change "false" to "true", which should make the Switch button visible again.
(In reply to John C. Beima from comment #57) > When is this being fixed? Taking user switching away from KDE desktop > installs of Fedora 34 is not a solution, it is hiding a problem that has > existed for more than a year. This challenge has been around since Fedora 32. > > You can't simply take user switching away from desktop machines, you are > making KDE simply an unusable desktop. The fact that this functionality has been increasingly breaking for two years, and got so broken that we don't even auto test for it anymore since Fedora 32 should tell you how little the functionality is actually used in practice. Nobody was working with upstream KDE to ensure this functionality worked for *years*. I would like to say we can restore it in Fedora Linux 35, but I honestly don't know if that will be the case. SDDM is going through a huge rework right now, and that may improve things on this front, or make it worse. I'm optimistic, but I can't reasonably say it'll happen for sure.
Is this still an issue? I see that KDE upstream bug mentioned has been marked as resolved. SDDM issue hadn't seen any comments. If it has been resolved is there a plan to enable this or how can I safely enable it now?
Hmm, I don't think we re-tested it this time around, really. Kamil, do you want to re-enable user switching and try it out a bit? I can do the same. Assuming we slip this week, we probably have time to turn it back on if it's working. Neal, Rex, any thoughts from KDE sig perspective?
well, I just re-enabled user switching and tried Kamil's scenario 2 - log in as user A, switch user, log in as user B, log out - and the system got stuck at a blank screen. So I'd say it doesn't look like things are hunky dory here yet...
Issue remains indeed, won't have a chance to test this until we can rebase to a newer sddm. And can't do that until xauth support is ported
(In reply to Rex Dieter from comment #63) > Issue remains indeed, won't have a chance to test this until we can rebase > to a newer sddm. > > And can't do that until xauth support is ported ... or we get to a point where SDDM can run in all scenarios in pure Wayland, which is dependent on bug 1986222.
(In reply to Neal Gompa from comment #64) > (In reply to Rex Dieter from comment #63) > > Issue remains indeed, won't have a chance to test this until we can rebase > > to a newer sddm. > > > > And can't do that until xauth support is ported > > ... or we get to a point where SDDM can run in all scenarios in pure > Wayland, which is dependent on bug 1986222. Speaking of, that bug was marked as a duplicate of Bug 2022385 which was closed with this message: > F36 was released today. If this Change did not land in the release, please notify bcotton as soon as possible. How does this impact this bug? What's the next thing blocking this from being fixed with a long-term solution (IE not hiding the button)?
I ran into this as I'm wanted to use user switching in Fedora 37. However in that release there no longer is a file named /etc/xdg/system.kdeglobals. Creating it manually to enter the configuration details as mentioned in comment 49 doesn't show the buttons. I presume this is because kdeglobals has been revised ? What is the current way to test user switching in Fedora 37 and up ? According to https://github.com/sddm/sddm/issues/1281 sddm has had a few bugfixes related to user switching. Perhaps we're in a better position to retry enabling it for KDE in fedora ?
Seems to work fine here on a pure Wayland setup with sddm. You can re-enable it by putting this in /etc/xdg/kdeglobals: [KDE Action Restrictions] action/start_new_session=true action/switch_user=true
from https://unix.stackexchange.com/questions/653940/switch-user-button-on-kde-plasma/653947#653947 https://pagure.io/fedora-kde/kde-settings/c/2d30395742e3e2414d9fa9d944d57049140466b0?branch=f34 You can re-enable it by editing /usr/share/kde-settings/kde-profile/default/xdg/kdeglobals and removing/commenting out the [KDE Action Restrictions] section (or setting to true) .