For starters, do you know if your laptop does S3 sleep or S0? I feel like the latter introduces a lot of uncertainty.

A lot depends on hardware actually, mix of USB Controller, video card, UEFI and etc type of suspeing s3,s0ix so huge fragmentation actually, it so bad that eveb on modern windows it holy crap shit not work because they forced on s2idle. Tell what ur hardware and please share journactl logs of when it fails

Kde on debian here. It just works nowadays

i dont really close my lid and walk away, i usually just lock the screen and turn off the display if required without suspending.

altho i have noticed users complain that suspend fails after a specific service/application is started so u might wanna check on that

Few seem to address the issue here : it does not work 100% of the time for you.

It might work for everybody else but that doesn’t help you much. You have your setup, no theirs.

So… you need to investigate. When it works, great, nothing to learn from. When it fails though… can you find a pattern? Does it always fail after you have use something specific? Check https://lemmy.ml/post/46800646/25494455 which gives examples of potential failure point and journalctl logs. You can then check what failed and if not you can at least know when then backtrack to others logs, e.g. dmesg.

They key take away is that when things do not behave as expected you need to put a detective hat on and you investigate :

• what’s your crime scene? Your laptop and it’s log files
• what’s the crime? It didn’t suspend properly
• where are the traces? In the logs
• where are the logs? Using journalctl or dmesg and typically in /var/log/
• what would a good detective do? Search for specific clues, e.g. places where fingerprints do stick, e.g metal or glass, which here would be error messages. That can be found using grep and other tools

You also have limited times because the logs will, just like on a real crime scene, get contaminated or rotated or deleted. So… if you do encounter the problem do not rush to the next tasks at hand because you are wasting an opportunity to learn and there is vanishing window.

TL;DR : grep logs

Depends a bit on your setup. If you’re using systemd you can use the logind.conf as already mentioned, or if you’re on a non-systemd distro you can use the forked elogind, which works pretty much the same way. For locking your session when suspending, since i use wayland, i use swayidle for that. In its config i just put before-sleep 'swaylock', which will execute swaylock before the system goes to sleep.

Inconsistent time before sleep is likely the kernel waiting for IO to sync to disk.

Not going to sleep at all implies a serious issue that prevented the kernel from doing so. Check your logs!

Suspend reliability greatly depends on the firmware of your specific device as it controls the wakeup.

On my Framework 16 for instance, it is very reliable these days. I can’t remember the last time it woke up unexpectedly and I’m not sure whether it happened even once since the firmware update that fixed a major oversight in keyboard wakeup (waking when a key was pressed through a closed lid).

I don’t know, I just installed Aurora Linux and everything works by default.

I bet your issue is hardware related, maybe you could change something in the bios to make it work.

Suspend and hibernate both work 100% of the time for me so far on both of my laptops, and have for as long as i’ve had them.

Thinkpad x270 Fedora (current) KDE spin

Thinkpad x250 Ubuntu 24.04 GNOME

Fully working since 2019 and 2016 respectively. I have not tested opening the lid after just 5 seconds so i can’t say for sure how long it takes.

My previous laptop before these (an x200) would sometimes fail to suspend and get super hot in my bag before running out of battery. I was using Gentoo at the time and i suspect i had something configured incorrectly. It only happened a few times but it was pretty frustrating.

I currently can’t get it working at all and had to disable it, because my machine won’t come back up. So i changed my workflow to take that into account. If I need it closed for a few minutes to move I leave it running and if the time window is greater I turn it off completely. There is always a way, my case is just very specific and I don’t necessarily need it. Anyway, good luck getting it to work the way you like.

In Hyprland, how it works is that you define the screen lock command (e.g. swaylock) in hypridle and that gets wired into logind somehow such that you can loginctl lock-session.

I then (also in hypridle) define a before sleep hook that locks the session.

I believe the proper way to do this would be to run your lockscreen as a systemd unit that is WantedBy and Before suspend.target. This would in theory take care of making it idempotent and reliably show the lockscreen before initiating suspend.
A friend of mine has this sort of setup and, while it is reliable, the lockscreen is still racy and sometimes only triggers after suspend. Might be the lockscreen unit not signalling its readiness to systemd properly though.