Suspend issues after update

Ask Fedora
, ,
1

I seem to have fixed this, but I’m not exactly sure what happened. I suspect regressions in packaging or something.

A few days ago, probably after some updates, my desktop PC (Fedora 43, Gnome, Wayland, AMD 6700 XT graphics) , stopped doing suspend when pressing the power button (pressing the button did nothing). It has worked fine since upgrading to Fedora 43 when it was released. I then checked in Gnome power settings and all suspend options were gone (i.e. the powerbutton setting and the suspend option). Googling and asking LLM hinted that the issue was with PAM. There has indeed been some pam updates this week. I then reinstalled pam and authselect-libs and did a reboot, but it didn’t help. Then I executed “sudo authselect select local --force --backup=pre-authselect”. This seemed to have fixed the issue after a reboot. The suspend options are now available again in system settings, and the PC suspends correctly from the power button.

But I’m not sure what broke suspend and why the authselect command seem to have fixed the issue.

2

So this is speculation, but possibly something in the PAM stack that got updated (module order, config defaults?), prevented pam_systemd.so from running in my session. So logind never got a proper session and Gnome disabled the suspend options, because it didn’t detect an authorized session. Restoring with “authselect select local” fixed the session, because the local profile includes pam_systemd.so.

Is this totally out of the blue?

4

There seems to be issues still after the above.

  1. Automatic suspend doesn’t work, even though it’s now possible to change in Gnome settings.
  2. When unlocking the screen, a black background is shown when entering the password, instead of the normal dimmed gnome lock screen background.

This indicates that the session is still not working properly. And indeed, there are two sessions after login with blocked idle detection:

$ loginctl list-sessions
SESSION UID USER SEAT LEADER CLASS TTY IDLE SINCE
2 1000 “myusername” - 3893 manager - no -
3 1000 “myusername” seat0 4087 user tty2 no -
2 sessions listed.

$ loginctl show-session 2 -p IdleHint
IdleHint=no
$ loginctl show-session 3 -p IdleHint
IdleHint=no

I don’t think the above is normal? Why the seatless “manager” session?

Could it be a bug in systemd-pam?

5

Don’t waste time on this. It seems that the latest systemd update requires a reboot. I also encountered all kind of issues after updating systemd.

6

I’ve rebooted multiple times. I’m sure something is broken. Can only hope a fix is coming. The weird thing I can’t find any bug reports with similar symptoms.

7

If you do:
In one terminal
journalctl -f | tee ~/suspend.txt

Open another terminal:
systemctl suspend

Is there anything that looks obviously broken in the text file?

8

No, this works fine. As I’d explained above, it works fine to do a manual suspend.

dec 25 22:07:33 myhostname systemd-logind[1264]: The system will suspend now!
dec 25 22:07:33 myhostname NetworkManager[1597]: [1766693253.8582] manager: sleep: sleep requested (sleeping: no enabled: yes)
dec 25 22:07:33 myhostname coolercontrold[1629]: Received message that system is going to sleep.
dec 25 22:07:33 myhostname ModemManager[1522]: [sleep-monitor-systemd] system is about to suspend
dec 25 22:07:33 myhostname NetworkManager[1597]: [1766693253.8586] device (wlp8s0): state change: unavailable → unmanaged (reason ‘unmanaged-nm-disabled’, managed-type: ‘full’)
dec 25 22:07:33 myhostname ModemManager[1522]: [sleep-monitor-systemd] ready to sleep; dropping inhibitor

Except for the odd symptom with the black login background afterwards.

9

There is one odd row:

systemd-logind[1264]: Delay lock is active (UID 1000/myusername, PID 35914/gnome-shell) but inhibitor timeout is reached.

So it detects the inhibitor, waits until timeout expired and forces suspend anyway. This follows the issues I’ve explained before.

1 Like
10

I tried disabling all gnome extensions. Suspending, and then resuming. The gdm login screen background was no longer black. I might be on to something.

1 Like
11

I wonder if you’re hitting Making sure you're not a bot!

If you run: systemd-inhibit --list after it fails to suspend is there anything interesting?

12

And now with disabled gnome-extensions, automatic suspend also works (I set it for 15 minutes). Now to figure out which extension causes it, or maybe all.

Definitely interesting.

I’ll try to figure out this as well.

13

This is really erratic. I enabled gnome extensions again, did a reboot, and now automatic suspend still works. So I think the extensions was a red herring.

One symptom remains. The login screen background is still black after suspend, and after locking the screen (it’s not black when logging in after a reboot).

So now I’m unable to repeat the no automatic suspend issue. I haven’t changed any system settings. Maybe it’s some user space program that occasionally does some activity or something. There is at least one in the inhibitor list:

$ systemd-inhibit --list
WHO            UID  USER PID   COMM           WHAT                                                     WHY                                       MODE
ModemManager   0    root 1420  ModemManager   sleep                                                    ModemManager needs to reset devices       delay
NetworkManager 0    root 1518  NetworkManager sleep                                                    NetworkManager needs to turn off networks delay
UPower         0    root 1278  upowerd        sleep                                                    Pause device polling                      delay
GNOME Shell    1000 user 18869 gnome-shell    sleep                                                    GNOME needs to lock the screen            delay
GNOME Shell    1000 user 18869 gnome-shell    sleep                                                    GNOME needs to save screen time data      delay
user           1000 user 19103 gsd-media-keys handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses                 block
user           1000 user 19103 gsd-media-keys sleep                                                    GNOME handling keypresses                 delay
user           1000 user 19113 gsd-power      sleep                                                    GNOME needs to lock the screen            delay
pcloud         1000 user 19139 pcloud         sleep                                                    Application cleanup before suspend        delay
14

Hi everyone, I upgraded from Fedora 42 Workstation to 43 and I’m having the same issue.
Also the button to suspend the PC from the lockscreen is missing…

15

You could try what I did:

sudo authselect select local --force --backup=pre-authselect

Then reboot. It didn’t fix all issues, but at least it’s possible to suspend manually.

Automatic suspend has mostly worked for me now. It failed once yesterday, but after a reboot it worked again. The lock screen background is still black.