Linux is cool, I can do a lot of things with it. If i set a config file in Linux, I am damn sure that it is ran every single time. The code does what you tell it to do.
There is 1 thing that always seems to be “black magic”: 1) lid close and suspend 2) lid close and suspend and lock.
If we ignore locking for a moment and focus on suspend. I cant seem to figure out why sometimes lid close would suspend immediately, when other time it takes 5 seconds after lid closes. On some days, lid closes would not even suspend !!
Did anyone manage to get suspend work 100 %? I cant believe we have tons of great linux tools and years into kernel dev, and still suspend is a hit or miss.
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
i got in the habit of doing this also because suspend didn’t work 100% of the time back then, but stopped when i switched to linux first laptops.
i switched back to a windows-first laptop recently and forgot about setting it so that it doesn’t auto suspend when i close the lid and it works just fine with fedora on it; linux has made leaps and bounds since the last time i contributed to it.
although, to be fair, i was on linux-first laptops for a decade so there was plenty of time to catch up. lol
lol , i hope linux develops more and becomes mainstream
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
journalctllogs. 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
journalctlordmesgand 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
grepand 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
Suspend is basically the same sensible balance used in booting, so yeah, hit or miss.
It works almost all the time. The times it doesn’t usually can be attributed to me not switching off my wireless mouse.
/etc/systemd/logind.confHandleLidSwitch=suspendAlso
HandleLidSwitchExternalPower=for when it’s still plugged in when you close the lid.NixOS for fun:
powerManagement.enable = true; services.logind.extraConfig = ''HandleLidSwitch=suspend'';Hows the maintenance on nixos? In reguards to updates. I really like arch for my dailies and have been running debain on my media device. I’m trying to find something that bridges that gap of more current packages and easy/low maintenance.
Been wanting to try it to see what it’s all about.
I’ve used Arch as my daily for so many years now, it is a little tricky moving from imperative to declarative configuration. I’m treating my NixOS machine more as long term maintenance, so I’m not using the most bleeding edge packages. You can do that though by pointing to
nixos-unstable.I plan on using flakes for pinning and home-manager for writing
~/.configconfigurations, but I don’t think I really need it, more just to learn how. With home-manager, I could rebuild this machine from scratch (including individual application preferences/settings) just with the backed up configs. I can at any point rollback to any saved previous generation though, too, just by restarting the machine.I’ve really been impressed with it though. To the point, I will probably be moving my Arch DIY router over and converting it to NixOS.
Thanks, maybe I’ll give it a shot soon.
i use fvwm. i have win l binded to xlock, so just press win l and close the lid.
In KDE it’s just a simple configuration in the power section of the settings. No idea what the general Linux way would be.
Any normal desktop environment should lock, then suspend. KDE does that afaik, never had that issue.
So first lock, then suspend. As the process is ran by the system, it doesnt care if the screen is locked or not.
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.You ask too much.
Sleep on Linux is never quite as reliable as it should be, and I end up with a laptop gently roasting itself to death in my bag more times than I’d prefer.
For starters, do you know if your laptop does S3 sleep or S0? I feel like the latter introduces a lot of uncertainty.
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.
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
Have a look on the Arch Linux wiki around
udevand event debugging (evdev?)Depending on whether you’re suspending to RAM or disk will affect the time it takes - and of course, how much stuff it has to suspend.
If you’re in the middle of a resource intensive task (which could just be watching a video… all depends…), then whatever is running needs to stop, and possibly has a full buffer which needs processing as suspend could be to the swap file / partition, which may need emptying first.
But, it should all work these days.
Kde on debian here. It just works nowadays
