GNOME 3: Cannot unlock screen saver (Fedora 31+, Ubuntu 20.04+, Solaris 11.4+)

[dcommander]

After swiping up to see the screen saver's password prompt, the password prompt continuously displays "Authentication error", even though nothing has been typed, and it doesn't allow the password to be typed. This is known to occur with TurboVNC, TigerVNC, and other X proxies running on Fedora 31+ and Ubuntu 20.04. It does not occur on RHEL/CentOS 8. In Fedora 32 and later, the issue manifests slightly differently. (The screen saver doesn't continuously display "Authentication error", and it does allow the password to be typed, but after typing it, the screen saver doesn't exit.)

Workaround:

• Set "Blank screen" to "Never" in the Power applet under GNOME Settings.
• If the screen saver is already locked, you can unlock it from an SSH session (or another X proxy session) by executing loginctl unlock-session

The workaround suggested here does not fix the issue.

[dcommander]

Some additional info:

With the latest TurboVNC release (including deleting ~/.vnc/xstartup.turbovnc so that the TurboVNC Server can re-write it) and Ubuntu 20.04 updates, I can now only reliably reproduce the issue in a TurboVNC session if GNOME 3 is also running in either a local session or a TigerVNC 1.11 session and the local session or TigerVNC session was started before the TurboVNC session. (TigerVNC 1.11 introduced a new systemd-friendly window manager startup mechanism, albeit one with serious limitations. You have to be root in order to configure and start a TigerVNC session now, TigerVNC sessions have to be started on specific X displays rather than automatically choosing an available X display, and you can't generally start multiple TigerVNC sessions with GNOME 3. Also, the window manager decorations in TigerVNC 1.11 running on Ubuntu 20.04 are just plain wrong.) The freeze seems to have something to do with D-Bus. TurboVNC sessions use independent D-Bus session addresses, so they don't seem to interfere with each other in this manner, but when a local or TigerVNC 1.11 session is also running, it seems to somehow hijack the screen saver in such a way that you can only unlock it from the local or TigerVNC session (which also unlocks the TurboVNC session.) Attempting to unlock it from the TurboVNC session produces the freeze. Unfortunately, I can now confirm that loginctl unlock-session doesn't work around the freeze. However, once you have managed to unlock the screen, you can run gsettings set org.gnome.desktop.lockdown disable-lock-screen true to prevent it from locking again.

[dcommander]

I was able to reproduce the issue both with TigerVNC on :1 and TurboVNC on :2 and vice versa, so the display number doesn't seem to matter.

[dcommander]

Further observations:

• Once the issue occurs, logging out of the local session or shutting down the TigerVNC 1.11 session doesn't make it go away. Even if you manage to unlock the screen in the TurboVNC session, the issue will return when it locks again.

• The issue can immediately be triggered if you know the TurboVNC session's D-Bus session address, which can be found by running

  cat ~/.dbus/session-bus/`cat /var/lib/dbus/machine-id`-{n}

  where {n} is the TurboVNC session's display number (e.g. 1, 2.) Then you can run

  dbus-send --bus={session-bus} --type=method_call --dest=org.gnome.ScreenSaver \
      /org/gnome/ScreenSaver org.gnome.ScreenSaver.Lock

  where {session-bus} is the D-Bus session address you obtained above.

• When the issue occurs, you can also unlock the TurboVNC session by running

  dbus-send --bus={session-bus} --type=method_call --dest=org.gnome.ScreenSaver \
      --print-reply --reply-timeout=20000 /org/gnome/ScreenSaver \
      org.gnome.ScreenSaver.SetActive boolean:false

• The session start order really does matter. If I start a TurboVNC session and then start a local or TigerVNC 1.11 session, I can't reproduce the issue. If I then shut down the TurboVNC session and restart it, the issue will occur.

• It doesn't seem to matter whether or not the screen is locked in the local or TigerVNC session.

• Removing unset DBUS_SESSION_BUS_ADDRESS from ~/.vnc/xstartup-turbovnc makes matters worse. If I do that, the TurboVNC session running GNOME 3 cannot co-exist with a local or TigerVNC 1.11 session running GNOME 3 at all.

[dcommander]

Another note regarding comparisons with TigerVNC:

This issue and #51 are the only known issues with GNOME 3 in a TurboVNC environment that are believed to be systemd-related. TigerVNC, despite using a systemd-friendly startup mechanism, also experiences #51.

There is no way to verify whether or not TigerVNC experiences this issue, because it simply does not allow multiple simultaneous GNOME 3 sessions under the same user account. If you are logged in locally with GNOME 3, attempting to start GNOME 3 in a TigerVNC session under the same user account results in a black screen. If you are running GNOME 3 in a TigerVNC session, attempting to start GNOME 3 in another TigerVNC session under the same user account similarly results in a black screen.

So the long and the short of it is: GNOME 3 is not multi-session-friendly, in general. TurboVNC's approach, which uses independent D-Bus session addresses for each VNC session, at least allows multiple GNOME 3 sessions to co-exist under the same user account, with a reasonable workaround. (If you don't want the screen saver to freeze, either disable screen saver locking-- which isn't very useful in a VNC session anyhow-- or don't try to use GNOME 3 simultaneously in a local and TurboVNC session or simultaneously in a TigerVNC and TurboVNC session.) I prefer our solution to not allowing multiple GNOME 3 sessions at all.

[levinit]

additional, ref https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/2196