GNOME Bugzilla – Bug 719418
login screen stuck after switching users
Last modified: 2015-03-17 16:41:50 UTC
It's easy and reproducible (always in my case) to make login screen stuck and eat 100% cpu. I have following users defined: test (with password) test2 (with password) kparal (without password) Reproducer: * Log in as 'test' * Switch user to 'test2' * Switch user to 'test' * Lock 'test's screen * From the unlock dialog, hit "Log in as a different user" * Log in as 'kparal' * See only grey screen, see CPU eat 100%, nothing happening Pstack claims:
+ Trace 232845
Thread 1 (Thread 0x7f340e504a40 (LWP 3003))
gnome-shell-3.10.2.1-2.fc20.x86_64, Fedora 20
Created attachment 262935 [details] system journal
Created attachment 262936 [details] gdm :0
Created attachment 262937 [details] gdm :1
Created attachment 262938 [details] gdm :2
Created attachment 262939 [details] rpm -qa
This sound like a duplicate of this of bug #709623. Can you try if you're also affected. I currently can trigger this in 2 of 5 tries.
(In reply to comment #6) > This sound like a duplicate of this of bug #709623. > Can you try if you're also affected. I currently can trigger this in 2 of 5 > tries. Yes, I can reproduce it. But they might not necessarily be duplicates. The developers need to decide that. Thanks for linking it, though.
Does this still happen with gnome-shell 3.14?
(In reply to comment #8) > Does this still happen with gnome-shell 3.14? Yes, tested with 3.14.1.5 in Fedora 21. Exactly the same approach.
To clarify, the reproducer in comment 0 is just a single use case of many. If you create a few users and then randomly log in/log out/switch/lock screen/etc between them, you'll see this bug in a minute or two. It's extremely easy to hit it. My reproducer is just a series of steps that trigger it easily and reliably.
I'd like to bring some attention to this issue. It's a showstopper when you want to use multiple users on a single machine (and fast-switch them, not just log out every time). My dad complained to me about this. My girlfriend regularly hits this on my laptop. Fortunately I'm often around, but what about those poor users who don't have me around? This is a generic issue. It's not hardware related. You don't need any luck to hit this. You don't need to follow my reproducer in the description. You just randomly switch users and you end up with a gray screen in a few minutes, every, single, time. Can we fix this, please? I would really appreciate it. Thanks a lot.
Created attachment 295173 [details] bug demonstration video Reproduced with gnome-shell 3.15.3 on Fedora Rawhide. The simplest reproducer I could find: 1. create two users (let's call them Red and Green), reboot 2. log in as Red, click Switch User 3. log in as Green, click Switch User 4. log in as Red, click Switch User 5. see blank gray screen I have attached a video demonstrating the steps above, please watch it. The two users have a different wallpaper (a red and a green one) so that you can easily distinguish them. After you end up in the gray screen, there's nothing you can do as a general user, there is no button and no keyboard shortcuts work (like ctrl+alt+del). I've tried to wait, and after waiting 7 minutes the screen was still all gray. The general user will need to hard-reset the machine. Power users can switch to the existing user sessions using Ctrl+Alt+Fx shortcuts. gnome-shell-3.15.3-1.fc22.x86_64 gdm-3.15.3.1-2.fc22.x86_64 systemd-218-3.fc22.x86_64 How reproducible: 100% confirmed on several different bare metal machines and also in a cleanly installed VM confirmed by different users (all of my family members) Additional info: I've tried to attach pstack output of important running processes once the gray screen bug occurred. Not sure how helpful it is. But there's no process which would be stuck and consumed 100% cpu.
Created attachment 295174 [details] rawhide - system journal
Created attachment 295175 [details] rawhide - rpm -qa
Created attachment 295176 [details] rawhide - gdm.pstack
Created attachment 295177 [details] rawhide - gdm-sessions-worker-gdm-launch-environment.pstack
Created attachment 295178 [details] rawhide - gnome-session-autostart-greeter.pstack
Created attachment 295179 [details] rawhide - gnome-shell.pstack
Created attachment 295180 [details] rawhide - Xorg-display-2.pstack
A downstream Fedora report is here: https://bugzilla.redhat.com/show_bug.cgi?id=1184933 I'm proposing this as a blocker bug for Fedora 22.
I coincidentally came up with a fix for this earlier today.
Created attachment 295219 [details] [review] manager: allow the login screen to do reauthentication At the moment, we only allow the user session to do reauthentication from its lock screen. If a user does user switching we instead open a new session for checking the user's password. This commit enables reauthentication from the login screen as well.
Attachment 295219 [details] pushed as 7295b0a - manager: allow the login screen to do reauthentication
It works. Thanks!
Created attachment 295299 [details] journal from rawhide VM Soo, I'm having some problems with the new gdm. I don't know whether it is still somewhat broken, or whether it just uncovered some other issue that was not accessible before. In Rawhide VM, I can switch between the users as many times as I want. But once I do "logout" for the second user (the green one), it seems to completely reset X server, because after a while (and some screen blinking) I arrive into gdm with *both* users logged out. The same happens on F21 VM with the new gdm update. However, if I try the same approach on a bare metal F21 system, I can't even switch the users properly. I can switch users once (red -> green), then I can switch green -> gdm, but once I enter the password for the red user and confirm it, the screen goes completely black. Not gray, as before, but black (backlight is still on). I can't switch VTs, I can't do anything. I can ssh in and gather logs, that's all. Journals attached.
Created attachment 295300 [details] journal from bare metal F21
As for the Rawhide VM, gdm crashes and ABRT claims it's this: https://retrace.fedoraproject.org/faf/reports/390194/ https://bugzilla.redhat.com/show_bug.cgi?id=1117791 I have made a full backtrace here: http://paste.fedoraproject.org/173740/22040819/
Created attachment 295302 [details] [review] manager: clean seed session when its display goes away If the display goes away right before the session exits, then we can crash because we'll try to finish the already finished display. This commit corrects the problem by making sure to dissociate the display from the seed session when the display is finished.
Comment on attachment 295302 [details] [review] manager: clean seed session when its display goes away Attachment 295302 [details] pushed as 259ef2d - manager: clean seed session when its display goes away
Seems to be an improvement. I noticed that using the same steps previously the problem didn't occur as quickly. I definitely had to repeat the login/logout/switch user activity more times than previous. This time it took about user changes before the issue happened. Again, it happens when one of the GDMs suddenly jumps from TTY3 to TTY7. Not sure why it skips 5 and 6. A user ended up with TTY4. As if right now, the issue exists on my PC. I have users on TTY1 and TTY4. Command line on TTY2, 5 & 6. A "good" GDM with user list on TTY3. A blank "bad" GDM on TTY7. From both users logged in, a Switch User command goes to the "bad" GDM and not the good one.
With gdm-3.15.3.1-4.fc22 (I assume that's the latest version), I still see gdm crash if I do this: 1. Log in as Red 2. Switch users 3 times: Red -> Green -> Red -> Green 3. Log out Green Traceback here:
+ Trace 234588
Thread 1 (Thread 0x7f5d3ca97840 (LWP 1078))
*** Bug 743554 has been marked as a duplicate of this bug. ***
I confirm this bug on fedora 21. This is, in my opinion, a severe problem for a family usage. I hope it can be fully fixed for gnome 3.16. Thanks.
Note: Ray, this bug is still, currently, blocking Fedora 22 Beta downstream, which means Fedora's expecting a fix in the next few weeks.
I think you misspoke, and meant to say: "fedora will help to find a fix in the next few weeks"
Adam, we haven't reached any agreement whether this should be a blocker bug or not. See "criterion update: add "switch user" to Shutdown, reboot, logout" thread spread over test@, desktop@ and kde@ list (it was accepted as a blocker by QA prior to that discussion, because we supposed that discussion would non-controversial). One further complication is that I realized we have yet another criterion covering this: "No part of any release-blocking desktop's panel (or equivalent) configuration may crash on startup or be entirely non-functional. " https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Desktop_panel and if you can't switch users even a few times, people can argue that the user switch menu item is "entirely non-functional". So, if there's a strong pushback from GNOME team on this functionality, the criterion will need to carry an explicit exception for this feature. Either way, we need to resolve this soon, before Beta.
Sorry if that was a little too concise. Kamil, the bug is on the current blockers list: it's an AcceptedBlocker. The discussion in question certainly exists, but right now it's on the list and no-one's proposed taking it off. What I wanted to convey was that the bug's currently on the blocker list, so if folks want to avoid a bunch of heartache about it down the road, we either need to find a fix or do something else about it...
All of this code was dramatically reworked in 3.15.90 ... is the problem still happening?
Thanks for info, Ray, I'll re-test tomorrow.
Created attachment 299101 [details] journal when mouse gets stuck It seems that some of those issues got fixed (yay!). I no longer see crashes or switches to an incorrect VT. However, after I switch user 4 times, the mouse stops working. I can't click on anything, nothing reacts on the cursor position (e.g. no highlight on mouse over). I don't see anything interesting in the journal, but I attached it here. When I switch back to gdm, it works again. After I log out all users, and log in again, it starts working again even in user sessions. Reproducer: 1. log in as Red 2. switch Red -> Green -> Red -> Green -> Red 3. see that your mouse doesn't work 4. switch to gdm, see that your mouse works 5. switch to Red again, see that the mouse doesn't work again 6. log out all users and log in as Red or Green again, see that mouse works now This is 100% reproducible for me. PS: All the time, I have an invisible cursor in gdm - it works, it's just invisible. It's visible in all user sessions. This might be related to the bug described above, but I haven't had time to debug it yet.
(In reply to Kamil Páral from comment #40) > PS: All the time, I have an invisible cursor in gdm - it works, it's just > invisible. It's visible in all user sessions. This might be related to the > bug described above, but I haven't had time to debug it yet. After further testing, this doesn't seem to be related. It's caused by having a USB Tablet assigned to that VM, and I guess wayland doesn't support tablets yet. If I remove it, the cursor in gdm becomes visible, but that does not affect the bug described in comment 40 (it still occurs). So, probably not related.
do you mind filing that separately against mutter? it's probably not GDM related.
Created attachment 299164 [details] missing users in gdm Unfortunately, while it seemed to be fixed in a VM, this is still not working on bare metal. I tried it on one of our machines, and after I perform Red -> Green -> Red -> gdm switch, I see no users in gdm to switch into. See attached screenshot.
Created attachment 299165 [details] system journal when there are missing users in gdm
That's with: gdm-3.15.91.2-1.fc22.x86_64 gnome-shell-3.15.91-1.fc22.x86_64 Ray, can you please tell me whether you can reproduce this? Simply create two passwordless users Red and Green with different wallpapers and switch back and forth between them. Thanks.
likely unrelated, likely bug 746079 I haven't tried reproducing it, but let's move the discussion off this bug.
(In reply to Ray Strode [halfline] from comment #46) > I haven't tried reproducing it, but let's move the discussion off this bug. ^ there should be a "yet" after "reproducing it" in that sentence
Created attachment 299197 [details] journal with gdm debug info This is the journal when I put Enable=true to the [debug] section of /etc/gdm/custom.conf and reproduced. The user-less login screen appeared at 13:27:00, give or take a few seconds.
Created attachment 299501 [details] [review] gdm: fix empty user list on user switching There's some vestigial code for hiding the user list that runs at the same time its parent is hidden. Only the parent should be hidden, at this point, so there's situations where the user list hides and never comes back. This commit fixes that, by deleting the vestigial code.
I tested with http://koji.fedoraproject.org/koji/taskinfo?taskID=9242017 (which should contain the patch above) on two different bare metal machines and it works in all of them! Yay! Thanks a lot, can you please push an update to F22 (and F21, if you think it should work as well)?
Review of attachment 299501 [details] [review]: OK
Attachment 299501 [details] pushed as b1de1ad - gdm: fix empty user list on user switching