Bug 1861700 - login stuck when changing users repeatedly (log out, log in a different one)
Summary: login stuck when changing users repeatedly (log out, log in a different one)
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: sddm
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Martin Bříza
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: BetaBlocker, F33BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2020-07-29 10:09 UTC by Kamil Páral
Modified: 2020-08-03 17:08 UTC (History)
8 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)
bug demonstration video (10.05 MB, video/x-matroska)
2020-07-29 10:12 UTC, Kamil Páral
no flags Details
journal (532.46 KB, text/plain)
2020-07-29 10:12 UTC, Kamil Páral
no flags Details
rpm -qa (58.05 KB, text/plain)
2020-07-29 10:13 UTC, Kamil Páral
no flags Details

Description Kamil Páral 2020-07-29 10:09:55 UTC
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):
sddm-0.18.1-6.fc33.x86_64
kf5-plasma-5.72.0-1.fc33.x86_64
plasma-user-manager-5.19.3-1.fc33.x86_64
Fedora-KDE-Live-x86_64-Rawhide-20200721.n.0.iso

How reproducible:
seems always

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).
3. reboot
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)

Additional info:
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.

Comment 1 Kamil Páral 2020-07-29 10:12:16 UTC
Created attachment 1702779 [details]
bug demonstration video

Comment 2 Kamil Páral 2020-07-29 10:12:52 UTC
Created attachment 1702780 [details]
journal

Comment 3 Kamil Páral 2020-07-29 10:13:00 UTC
Created attachment 1702781 [details]
rpm -qa

Comment 4 Kamil Páral 2020-07-29 11:19:02 UTC
(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.

Comment 5 Kamil Páral 2020-07-29 17:16:16 UTC
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."
https://fedoraproject.org/wiki/Basic_Release_Criteria#Expected_installed_system_boot_behavior

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.

Comment 6 Rex Dieter 2020-07-29 20:51:51 UTC
Looks like another variant of (largely) well-known bug #1817708 , where processes from previous sessions persist causing subsequent logins to fail.

-1 blocker

Comment 7 Kamil Páral 2020-07-30 11:29:29 UTC
(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.

Comment 8 Kamil Páral 2020-07-30 14:08:03 UTC
(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.

Comment 9 Rex Dieter 2020-07-30 14:29:23 UTC
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.

Comment 10 Kamil Páral 2020-07-30 14:49:53 UTC
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":
https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process#Exceptional_cases
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.

Comment 11 Geoffrey Marr 2020-08-03 17:08:19 UTC
Discussed during the 2020-08-03 blocker review meeting: [0]

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.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-08-03/f33-blocker-review.2020-08-03-16.02.txt


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