Bug#973831: gnome-shell: Login hangs after system suspend

[Simon McVittie]

Control: tags -1 + moreinfo

On Thu, 05 Nov 2020 at 14:08:25 -0500, Calum McConnell wrote:
> After a suspend, my laptop will present me with the username/password
> prompt, at which point I can login and return to work.

To confirm what you are seeing, does it look like the second screenshot
here?
https://help.gnome.org/misc/release-notes/3.6/users-lock-screen.html.en

> However,
> in many cases, after entering the password and pressing "enter",
> the login simply hangs, triggering only some disk activity.

Are you using any GNOME Shell extensions? If you are, please try
disabling them and rebooting, and see whether this persists.

Are you using ordinary local storage for user accounts and passwords,
or are you using anything network-based like LDAP? Please send the
passwd, group and shadow lines from /etc/nsswitch.conf, and the
contents of /etc/pam.d/common-* and /etc/pam.d/gdm-password.

Do gnome-shell 3.38.1-3 and mutter 3.38.1-3, both available in
experimental, make any difference to this? These add patches from
upstream that will eventually be released as 3.38.2.

Some probably-unrelated fixes in those versions should at least reduce
the amount of noise in your system log, which might make it easier to
see what is going on.

Since this is timing-related, it might help to create a temporary user
account, change its password to be 1 letter long, and use that for
further testing, so that the time it takes you to actually type the
password doesn't have a significant effect.

One thing that might help here is if you can wake up the laptop at a
known time (for instance synchronize a clock with the laptop's and wake
it up when the seconds read :00), then note what the time is when you
press Enter after your password, and tell us those times so we can
correlate them with timestamps in the log.

> The bug is NOT triggered if I wait a few seconds before entering my
> password.

Approximately how long in seconds do you need to wait between wakeup and
pressing Enter for the password, to make it reasonably reliable?

It would probably be useful to compare a system log from an attempt in
which you went too fast and saw this bug, and a system log in which you
waited a few seconds and did not see this bug.

> If I
> leave it alone for a few minnutes, it eventually presents me with a
> screen containing the system time, at which point I can once again
> provide input, returning to the login screen and signing in.

Like the first screenshot here?
https://help.gnome.org/misc/release-notes/3.6/users-lock-screen.html.en

(That's the "lock screen" in user-facing documentation or the "screen
shield" in the source code.)

> I have been frequently experiencing this issue on this laptop,
> which has been running Bullseye since June.

Is there any recent version that *didn't* have this issue?

If you have experienced this ever since upgrading from buster to
bullseye, then it's going to be difficult to isolate which specific
component triggers this: it could be gnome-shell or mutter, but it
could also be influenced by the user-space graphics drivers (Mesa)
or by the kernel.

> I have found several other related threads about this issue,
> but none seem to present a solution.  This includes gdm issue
> 618

(That's https://gitlab.gnome.org/GNOME/gdm/-/issues/618)

Do you have any autofs or systemd automount units to mount network shares?

> and askUbuntu question 1140365

(That's
https://askubuntu.com/questions/1140365/18-04-login-screens-hangs-after-suspend-or-lock)

> neither has received any attention

Diagnosing bugs from unclear symptoms is really difficult to do,
particularly if a developer doesn't see the same symptoms themselves,
so what attention these have received will often take the form of:
developer looks at bug report, developer thinks "I have no idea what's
going on here", developer works on something they *can* solve instead.

    smcv