Description of problem: In this situation, I'm seeing "Authentication error" in gdm even before I enter a password. Version-Release number of selected component (if applicable): gdm-3.28.2-1.fc28.x86_64 How reproducible: I've reproduced this several times inside a VM, with no failures to reproduce. Steps to Reproduce: 1. Create second user for testing. 2. Reboot 3. Login to user 1. 4. Ctrl+alt+f1 5. Click on user 2 Actual results: GDM shows "Authentication error" for a second, then goes back to the user list. Retrying a second time does not show the error (and allows an apparently successful login as user 2). Expected results: "Authentication error" does not happen before I have entered a password. Additional info: This appears to trigger this log message: May 28 15:09:20 fedora28-vm gdm[752]: GdmSession: conversation gdm-password started more than once May 28 15:09:20 fedora28-vm gnome-shell[894]: JS ERROR: Failed to start verification for user: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.> _startService/<@resource:///org/gnome/shell/gdm/util.js:436:20 Also, if, after the authentication error, you try to log back in to user 1, it lets you enter a password, but just kicks you back to the user list. The system log shows an immediate logout, and nothing else I recognize. May 28 15:16:02 fedora28-vm gdm-password][2461]: pam_unix(gdm-password:session): session closed for user alan-test May 28 15:16:02 fedora28-vm gdm[762]: GdmDisplay: display lasted 0.277620 seconds
Also, after the authentication error, if you switch back to user 1 using ctrl+alt+f2, you will notice that `loginctl session-status` now shows `Status: closing` instead of `Status: active`. As a result, you lose permission to shut down the system (or suspend) without entering a password, change the brightness of a laptop display, etc. Anything that the PolKit configuration requires you to have an active session for. These are all because the PID which `loginctl session-status` shows as `Leader: `, has exited. That process is the one named `gdm-session-worker [pam/gdm-password]`.
This also happens if you replace step 4 (ctrl+alt+f1), with clicking on the Lock icon, and then clicking "log in as another user".
I have looked into the source of gdm. In function gdm_session_start_conversation() in daemon/gdm-session.c, the worker is killed because of a hash table lookup. Since the service name just seems to be "pam/gdm-password", there will be a collision and the existing worker gets the TERM signal. I don't know the service name concept in detail, but maybe it is possible to add a session id or user name here (but with user name, there might be the same issue than clicking on the same user in gdm who is currently logged in)
Created attachment 1453180 [details] messages including "started more than once", with debug messages enabled this time I should have pointed out this is a regression in Fedora 28. I used user switching very regularly with GDM on Fedora 27, and that was working ok. It looks like there's supposed to be multiple gdm-session objects, one for each logged in user (and one for the greeter itself). So it shouldn't matter that each session can only have one "pam/gdm-password" worker. It suggests the problem is that GDM is manipulating the wrong gdm-session object. I can't find why though.[1] I tried enabling debug messages while reproducing this, see attached. I can't find a smoking gun in there. Btw I think "service name" means the PAM service name, as in /etc/pam.d/, e.g. there is "gdm-password" for gdm password logins, "gdm-fingerprint"... Other users of PAM use different service names, e.g. there is a "sshd" service name.
I am having similar problems since my recent upgrade from f27 to f28. I had come to a similar conclusion, both users can initially log on, but subsequent attempts to switch users/login fail. I suspect it is trying to open new sessions rather than reopen the existing.
I verified that this happens on a clean install of Fedora 28, although I also see this on upgraded systems from F27 to F28.
does anyone has a running fedora 27 and could check the "Service:" line from "loginctl session-status"? Is it also "gdm-password"?
I have set up a VM with F27 and yes, looking at loginctl, it all looks the same. I will dig a bit deeper into it.
I installed a VM from the live iso image and it worked. after dnf up, it fails running dnf downgrade gdm fixes it. So this is a regression between gdm-1:3.28.1-1.fc28 and gdm-1:3.28.2-1.fc28.
So, good news. I applied the patches from the gnome-3.28 branch of gdm after 3.28.2 and it works. So, this issue should be solved with the 3.28.3 release - whenever this happens.
sounds like this is a good candidate for a backport, regardless of the gnome 3.28.3 schedule. (Also being bitten by this. Quite annoying)
Possibly related to upstream https://gitlab.gnome.org/GNOME/gdm/issues/386 and the related MR is possibly what fixes it in 3.28.3.
So this is no longer happening for me on F28 with gdm-3.28.4-1.fc28.x86_64
Wooo! Thanks everyone.