I am under the impression that this was a more general Windows issue. Does someone else have more information?
I am under the impression that this was a more general Windows issue. Does someone else have more information?
1. Linux kernel "mem-sleep" mode default [0], which determines what actually happens when systemd-sleep "suspend" is called. The default value is "s2idle" for many distros which is as good as leaving your computer running with processes paused... when what most users expect is some kind of suspend-to-ram ("deep"). Obviously this burns through battery pretty quickly but at least it shouldn't overheat.
2. I found this systemd infinite hybernate loop bug [1] (now fixed) when swap is smaller than RAM... although you only would come across this is you accidentally under-provisioned the swap partition on install like I did - but the failure mode was spectacularly bad, because it will retry over and over swapping and compressing the RAM which obviously ramps up the CPU, get hot with the lid closed, make short work of battery and SSD.
Anyway the common issue is #1 which you just have to know about otherwise your computer doesn't really suspend at all, and since most machines are very quiet these days you won't notice unless you dig.
[0] https://unix.stackexchange.com/questions/538541/suspend-to-r...
I'm still having an issue where double-finger-touchpad-scrolling causes my X server to core dump, and I can't force the X server to actually dump a core file, because I can't run `ulimit` before the X server runs. You're kind of just shit out of luck as a Linux user.
As an extreme option you can always replace the binary with a shell script setting ulimit and exec-ing the original Xorg.
At least one of those is mentioned there. But a lot of it depends on the implementation by the OEM, ultimately.
The default behaviour is unintuitive to most people and often they are not even aware it's not doing what they expect. This is the problem, not that it doesn't work, but that it doesn't work by default.
powercfg -lastwake
This will tell you which action or hardware initiated the wake. It should provide enough clue of the offending software. Also the wakes are recorded in the log, you would be able to pull up the event viewer to find the lists of the offending software that abuses this. There is a event ID for it which you can use to track this down, I couldn't remember the number.
Edit: Here the guide for finding this in the event viewer.[0]
[0] https://www.tenforums.com/tutorials/63136-see-wake-source-wi...
> On occasion, the system stays in the active mode (with the screen off) for a longer interval of time. These longer active intervals occur for a variety of reasons, for example, processing incoming email or downloading critical Windows updates.