Description of problem: When user1 is already logged into GNOME, locks his session, and user2 logs in, user2's screen is locked immediately after logging in. When user2 keeps logging in, his screen is locked approximately every 10 seconds. The locked screen shows user1's name (so not only user2 is locked, the screen also switches to user1's lock screen every time). See the attached video demonstration. User1 = kparal, user2 = tester. This means that once user1 is logged in, the system is completely unusable for user2. Only once user1 fully logs out, user2 can log in and work as normal. Note that both user1 and user2 session continue to run, they are not killed. It's just the lock screen that kicks in periodically and frequently for user2. This is happening both in VM and on bare metal. Version-Release number of selected component (if applicable): gnome-shell-3.33.92-1.fc31.x86_64 gnome-session-3.33.92-1.fc31.x86_64 gdm-3.33.92-1.fc31.x86_64 systemd-243-1.fc31.x86_64 How reproducible: always Steps to Reproduce: 1. create two users 2. log in with the first one, open up some app to see whether the session is running or killed 3. lock the session, use "log in as different user" 4. log in as the second user 5. see that your session is locked immediately and you are switched to the first user's lock screen 6. be persistent, use "log in as different user" and log in again 7. open up some app to see whether the session is running or gets killed 8. see your session locked in ~10 seconds 9. repeat 6. and 8. as long as you like Additional info: If you look carefully or step over frames in the video, you'll see that during the subsequent user2 login attempts you can see a VT flash with some text on it. The text shows "clock" in my case, which is exactly the text I typed into gnome-shell overview when logged in as user2. So it seems to be echoing everything typed into shell. Alciregi claims he saw his user password shown in there [1], but I couldn't repeat that, I saw just the text I typed into gnome-shell overview. [1] https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/7F5T7AUO22JV2LGLUQA6PINNZN6XVWXB/
Created attachment 1614456 [details] video bug demonstration This is a recording of a VM where the problem is demonstrated with two users.
Created attachment 1614458 [details] VT flash containing text user2 typed This is the VT flash that shows what user2 typed into gnome-shell overview while logged in. It is not very visible in the video, but on bare metal the flash was more noticeable and you could be quick enough to read the text.
Created attachment 1614459 [details] journal System journal gathered after capturing the video.
Created attachment 1614460 [details] rpm -qa output
I propose this as a F31 blocker. The closest criterion could be: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use. " https://fedoraproject.org/wiki/Fedora_31_Final_Release_Criteria#Default_panel_functionality In this case, either the lock feature doesn't work properly (and activates when it should not), or the login functionality somehow breaks the second user session.
+1 blocker, user switching should be expected to work
I think the GDM auto-shutdown is triggering this. i.e. the "c2"/"c3"/... sessions that the GDM user has for the login screen are terminated, and this is triggering a VT switch to the first user session for some reason. I bet the second users session is not even locked, i.e. if you hit Ctrl+Alt+Fx to switch to it, you will find an unlocked GNOME session just sitting there. I have no idea what component is triggering the VT switch though. Suspects for this could be logind or the mutter/Xorg from the old GDM session during shutdown.
I think a good start for debugging could be to "strace -e ioctl -p X" the systemd-logind process. Specifically looking for VT_ACTIVATE ioctls.
So, what happens is that GDM shuts down, the "gdm-session-worker [pam/gdm-launch-environment]" process calls gdm_session_worker_uninitialize_pam internally. This in turn triggers a VT switch to "login_vt". "login_vt" seems to be the VT that was active when the GDM screen was started (i.e. the one where you press "Login as other user"). Maybe there should be a guard that the VT is only switched if "session_vt" is currently the active one VT. I somewhat suspect that this is not a regression, but I have not verified this.
Actually, this might have worked fine in the past. There are two ways for gdm_session_worker_uninitialize_pam to be called: * When the worker child exits * When gdm_session_worker_finalize is called And, the call to gdm_session_worker_uninitialize_pam in finalize was only added recently in https://gitlab.gnome.org/GNOME/gdm/commit/3e8220921bb608afd06ed677104fd2244b901a28. So, I suspect we almost always hit the codepath that was recently fixed in practice, triggering the issue.
Probably obvious, but I tested with GNOME 3.34, this is unchanged, still happening. gnome-shell-3.34.0-1.fc31.x86_64 gnome-session-3.34.0-1.fc31.x86_64 gdm-3.34.0-1.fc31.x86_64 systemd-243-1.fc31.x86_64 > I bet the second users session is not even locked, i.e. if you hit Ctrl+Alt+Fx to switch to it, you will find an unlocked GNOME session just sitting there. Correct. Once I switch with Ctrl+Alt+F3 to the user2's session, it no longer switches away automatically. > I somewhat suspect that this is not a regression, but I have not verified this. It's working fine on Fedora 30, I and my wife switch between accounts regularly. Also tested in a VM just now.
Discussed during the 2019-09-16 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker" was made as it violates the following criterion: "All elements of the default panel (or equivalent) configuration in all release-blocking desktops must function correctly in typical use" [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-16/f31-blocker-review.2019-09-16-16.02.txt
*** Bug 1755078 has been marked as a duplicate of this bug. ***
Upstream fix: https://gitlab.gnome.org/GNOME/gdm/merge_requests/86 Scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=37857124 PR for the GDM package: https://src.fedoraproject.org/rpms/gdm/pull-request/5 Thanks to Hans for the input and making sure we are getting this right!
FEDORA-2019-4339a442d3 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-4339a442d3
gdm-3.34.0-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-4339a442d3
(In reply to Fedora Update System from comment #15) > FEDORA-2019-4339a442d3 has been submitted as an update to Fedora 31. > https://bodhi.fedoraproject.org/updates/FEDORA-2019-4339a442d3 Thanks Benjamin, this update fixes the problem in my testing. (The only nitpick I still have is that "Switch User" is no longer present in user menu, so you have to lock & go to gdm every single time. But I don't know whether it's a bug, might be intentional.)
Yeah, I realised the lack of "Switch User" yesterday only. It is a separate issue, and a quick look suggests that this is something that needs to be tackled in accountsservice. Do you know if we already have a bug for that?
(In reply to Benjamin Berg from comment #18) > Yeah, I realised the lack of "Switch User" yesterday only. It is a separate > issue, and a quick look suggests that this is something that needs to be > tackled in accountsservice. > > Do you know if we already have a bug for that? It was fixed not that long time ago in bug 1576903. Perhaps the fix disappeared somehow from F31? Either way, I created bug 1755838.
gdm-3.34.0-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.