Description of problem:
On F33 KDE, I can't switch repeatedly between several users. Once I try to log in with a user which has been logged in before (and now is logged out), the screen shows a very long spinning circle and then a black screen. No action is possible at that point. If I manually switch to VT2 and reboot, the reboot is waiting 90 seconds for pending user sessions. There is something stuck when starting those user sessions.
See attached video.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. install KDE from Fedora-KDE-Live-x86_64-Rawhide-20200721.n.0.iso
2. create two users - user1 and user2. (I marked user1 as admin and not user2, but that shouldn't be important).
4. log in as user1
5. log out
6. log in as user2
7. log out
8. log in as user1 - see a very log spinning circle and then an endless black screen (with a functioning cursor)
I tried the same procedure without user2, i.e. just log in user1, log out, log in user1 - and that works, even repeatedly. This is somehow related to the session that user2 starts and stops between those steps.
Also please note that I see "Process 1518 (kglobalaccel5) of user 1001 dumped core." and "Process 2215 (kglobalaccel5) of user 1002 dumped core" in the journal. I'm not sure if it is related to the login issue or not. I'll try to report the crash in a separate bug, but abrt currently claims "Error: File './coredump' is not a coredump", so I can't easily report it.
Created attachment 1702779 [details]
bug demonstration video
Created attachment 1702780 [details]
Created attachment 1702781 [details]
(In reply to Kamil Páral from comment #0)
> Also please note that I see "Process 1518 (kglobalaccel5) of user 1001
> dumped core." and "Process 2215 (kglobalaccel5) of user 1002 dumped core" in
> the journal. I'm not sure if it is related to the login issue or not. I'll
> try to report the crash in a separate bug, but abrt currently claims "Error:
> File './coredump' is not a coredump", so I can't easily report it.
That is bug 1860616, it seems abrt doesn't support zstd-compressed coredumps currently.
Proposing as an F33 blocker. The most fitting criterion might be this:
"A system installed with a release-blocking desktop must boot to a log in screen where it is possible to log in to a working desktop using a user account created during installation or a 'first boot' utility."
The login process works initially, but stops working after following the sequence of actions described in comment 0. If people feel this criterion is not a good candidate, then it's time to refine it or create a new one. We have precise criteria about everything else (log out, user switching, reboot, shutdown, etc), but we don't have a criterion which would say "login must work (every time)". We can add it, if needed.
Looks like another variant of (largely) well-known bug #1817708 , where processes from previous sessions persist causing subsequent logins to fail.
(In reply to Rex Dieter from comment #6)
> Looks like another variant of (largely) well-known bug #1817708 , where
> processes from previous sessions persist causing subsequent logins to fail.
> -1 blocker
I intend to propose all user switching-related bugs as blockers, now that we have a specific criterion for it in F33. This bug might or might not be related, but I'm not sure if it's relevant for the release blocking decision. Bug 1817708 was rejected as a blocker, because we didn't have a user switching criterion at that time. Now we have. If user switching is definitely covered by criteria now, it seems silly not to hold basic user login to at least the same standards. As I said, we can clarify the criteria as needed, if stakeholders agree. What is your rationale for -1 blocker? Thanks.
(In reply to Kamil Páral from comment #7)
> I intend to propose all user switching-related bugs as blockers, now that we
> have a specific criterion for it in F33.
Actually, I need to clarify this. I just found out that user switching in no longer available in F33 KDE (not sure whether it is a bug or intentional). As long as it is not offered to the user, I can't of course propose them as blockers. So I'll keep to just user login/logout testing for now. I'll individually report the user switching issues and propose them as blockers, once/if user switching is offered again in KDE.
My objection was mostly about how to deal with the blocker. I feel not enough is known about the root cause(s), much less how to diagnose and fix them. In this specific case in particular, so a user has processes lingering after log out. What's to blame? Who's job is it to fix that? *This* bug was filed against sddm, a component I have large doubts has little to do with the root problem.
Thanks for reply, Rex. I chose sddm because it's at least partially related, I don't know the root cause and the actual culprit either. I hope that's something that developers can figure out! :-) I'll be happy to provide as many details as I can, and test different approaches to help pinpoint the root cause better. Sddm is just a temporary station here, if this turns out to be systemd-related (or we suspect it could), we can reassign there. We can also move this to "distribution", if you prefer. If this turns out to be a hard nut to crack, we have options how to deal with it, e.g. with "Difficult to fix blocker bugs":
Or there can be other ways to handle this, but basically the unknown factor (what caused it? how to fix it?) shouldn't affect the blocker decision.
Discussed during the 2020-08-03 blocker review meeting: 
The decision to delay the classification of this as a blocker bug was made as we acknowledge that this is a bad bug and perhaps intellectually violates the criteria, however we don’t believe we have a specific criterion to use against this bug at the moment. We will punt for now and send out mail to discuss implementing a new criterion or redefining an existing one.