Slow wake from suspend

Ever since upgrading to Fedora 34 (from 33) I’ve noticed that the system is much slower to wake from sleep/suspend.

What happens:
When waking the computer from suspend, the screen remains black until I press a key. Sometimes I need to press a key multiple times before the gdm shows up.
I’ve also noticed that, sometimes, I am unable to reach the password prompt via keyboard and have to click anywhere to make it available.

What was expected:
Snappy response when waking from sleep and no unnecessary keystrokes/inputs

What I tried:
I tried deactivating GNOME shell extensions, but nothing changed

Any ideas?

1 Like

Could you take a look at the journal to see what messages are noted during the suspend/wake bit? That may give us some clues on what is holding it up:

Hi Ankur, thanks for your reply.
Here’s a log snippet covering the portion from the moment I put the computer in suspend mode to the moment I access the desktop again

Idk, but it looks like it might be a keyring problem. Which would be consistent with a recent issue I was facing:

1 Like

Shell Extensions are fully deactivated btw and the problem existed before I resorted to deleting my keyring as mentioned in the linked thread

1 Like

I see slack.desktop making lots of network requests—I wonder if that contributes some to the delay.

There’s this too:

gnome-shell[6200]: Usage of is deprecated for AuthPrompt

which may be related to the the key press not bringing up the login/password screen,
and there are a few of these that look related to the keyring issue:

goa-daemon[6470]: secret_password_lookup_sync() returned NULL
goa-daemon[6470]: secret_password_lookup_sync() returned NULL
goa-daemon[6470]: secret_password_lookup_sync() returned NULL
goa-daemon[6470]: secret_password_lookup_sync() returned NULL

Just as a test, could you create a new user and see how suspend/resume works there? That’ll help us decide if its a system level issue or a user specific one.

1 Like

So quitting slack had no effect.
Suspend/resume works perfectly under a new user account, however.
Any ideas for the next step?

1 Like

That suggests it’s something specific to the account then. I guess comparing the suspend/resume logs when using the two users would be a start? That may tell us what components are running/behaving differently?

1 Like

Oddly it seems the problem may have propagated to the new user as I’m encountering the same issue again: i.e screen remains black after resume, need to press a key to activate display.

Here’s the log for the new user:

There seems to be some common errors in the new user’s log only if both sessions are ‘active’. i.e. if is switch users via the top-right dialog.

new user’s log after switching from main user: