🐧 PSA: Systemd intentionally draining laptop batteries if using suspend-then-resume since systemd-252
Nachrichtenbereich: 🐧 Linux Tipps
🔗 Quelle: reddit.com
As of Systemd-252, systemd incompatibly changed the existing suspend-then-hibernate feature, and specifically HibernateDelaySec
, from what it was well established and documented to do, to instead wait that time, and then guess how long your battery will last *, and *only if its almost out will it try (and usually fail/die before then) to hibernate.
Why they decided to incompatibly change an existing option to do something entirely different and break every single user, and cause data loss, is beyond me.
This behavior is absolutely ridiculous, look at the nonsense it is now
suspend-then-hibernate
A low power state where initially user.slice unit is freezed. If the hardware supports low-battery alarms (ACPI _BTP), then the system is first suspended (the state is stored in RAM) and then hibernates if the system is woken up by the hardware via ACPI low-battery signal. Unit user.slice is thawed when system returns from hibernation. If the hardware does not support low-battery alarms (ACPI _BTP), then the system is suspended based on battery's current percentage capacity. If the current battery capacity is higher than 5%, the system suspends for interval calculated using battery discharge rate per hour or HibernateDelaySec= if former is not available. Battery discharge rate per hour is stored in a file which is created after initial suspend-resume cycle. The value is calculated using battery decreasing charge level over a timespan for which system was suspended. For each battery connected to the system, there is a unique entry. After RTC alarm wakeup from suspend, battery discharge rate per hour is again estimated. If the current battery charge level is equal to or less than 5%, the system will be hibernated (the state is then stored on disk) else the system goes back to suspend for the interval calculated using battery discharge rate per hour. In case of manual wakeup, if the battery was discharged while the system was suspended, the battery discharge rate is estimated and stored on the filesystem. In case the system is woken up by the hardware via the ACPI low-battery signal, then it hibernates.
compared to before
suspend-then-hibernate A low power state where the system is initially suspended (the state is stored in RAM). If not interrupted within the delay specified by HibernateDelaySec=, the system will be woken using an RTC alarm and hibernated (the state is then stored on disk).
If you're using a laptop and were using this option, beware. You can guess how well the new behavior actually works. Heres a hint: It doesn't. Way more complex, way less reliable, and completely different from what it was, changed with no warning, and practically guarantees data loss and battery drain.
[link] [comments] ...
🐧 Suspend shuts down laptop (Manjaro-i3)
📈 23.72 Punkte
🐧 Linux Tipps
🐧 Intentionally Virtualizing at Work
📈 21.6 Punkte
🐧 Linux Tipps