After the sd-bus port of logind there are problems with the lock screen in gnome-shell. It just appears to be in a loop showing the message "Authentication problem".

I have narrowed down the issue but I am not confident in where the fix should be made.

I have bisected the problem to the sd-bus port commit:
http://cgit.freedesktop.org/systemd/systemd/commit/?id=cc3773810855956bad92337cee8fa193584ab62e

The journal will fill up with repeated messages of:
gnome-session[1214]: (gnome-shell:1375): Gjs-WARNING **: JS ERROR: Failed to open reauthentication channel: Gio.DBusError: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: No sessions for thomas available for reauthentication
gnome-session[1214]: ShellUserVerifier<._reauthenticationChannelOpened@/usr/share/gnome-shell/js/gdm/util.js:327
gnome-session[1214]: wrapper@/usr/share/gjs-1.0/lang.js:213

The problem starts in gdm's get_session_id_for_user_on_seat_systemd:
https://git.gnome.org/browse/gdm/tree/daemon/gdm-manager.c?id=daa93cb4729cb6cd62576d88078e3eb7436ae62e

Specifically in the loop over all sessions where it checks sd_session_get_state. There gdm will get the wrong state for the current sessions. sd_session_get_state will read the state directly from the session file in /run/systemd/sessions. After the sd-bus port this file claims that "STATE=closing". Gdm will thus skip the session because it is closing and in the end will not have found the session it is trying to reauthenticate.

If we use "loginctl show-session" it will report the same session as "active". The session file and logind are out of sync.

A way to get out the problem is to switch to another tty and then back to tty1. This will cause the session file to be updated and the lock screen no longer has any problem.