+++ This bug was initially created as a clone of Bug #1751673 +++
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 = varshit, user2 = himank.
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/
--- Additional comment from Kamil Páral on 2019-09-12 11:22:28 UTC ---
This is a recording of a VM where the problem is demonstrated with two users.
--- Additional comment from Kamil Páral on 2019-09-12 11:33:25 UTC ---
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.
--- Additional comment from Kamil Páral on 2019-09-12 11:35:16 UTC ---
System journal gathered after capturing the video.
--- Additional comment from Kamil Páral on 2019-09-12 11:35:34 UTC ---
--- Additional comment from Kamil Páral on 2019-09-12 11:41:06 UTC ---
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.
--- Additional comment from Michael Catanzaro on 2019-09-13 23:02:10 UTC ---
+1 blocker, user switching should be expected to work
--- Additional comment from Benjamin Berg on 2019-09-14 07:33:34 UTC ---
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.
--- Additional comment from Benjamin Berg on 2019-09-14 07:37:54 UTC ---
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.
--- Additional comment from Benjamin Berg on 2019-09-16 14:33:37 UTC ---
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.
--- Additional comment from Benjamin Berg on 2019-09-16 14:46:12 UTC ---
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.
--- Additional comment from Kamil Páral on 2019-09-16 14:50:40 UTC ---
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.
--- Additional comment from Geoffrey Marr on 2019-09-16 18:15:52 UTC ---
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