Bug 1751673

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.