[opensuse-factory] TW auto suspend on low battery level
![](https://seccdn.libravatar.org/avatar/9f2f2d6d8b992b9993de56518908bde2.jpg?s=120&d=mm&r=g)
Hello, During time I lost the benefits of having a working automatic suspend or hibernate function on my laptop for a certain level of low battery percentage. I don't know which has been the root cause that broken auto-suspend, if the abandon of pm-utils, systemd or kernel or whatsoever, the fact is that nothing seems working anymore now also by attempting to reconfigure DE power managers. So I decided to Google and finally I found a perfectly working alternative; I just tested on my Tumbleweed and it works perfectly. I'm posting here because opensuse-factory is currently the only one M.L. I'm subscribed too. Hope somebody else could have the necessity to have a working suspend feature on low batt. on his laptop. 1) put this script in your /usr/local/bin and set execution permission: /usr/local/binlowbattcheck.sh #!/bin/bash if [ $(cat /sys/class/power_supply/ACAD/online) -eq 0 ] && [ $(cat /sys/class/power_supply/BAT1/capacity) -lt 5 ] then /usr/bin/systemctl suspend fi It starts _only_ if your power supply is not plugged and if the battery capacity goes below 5% 2) create this systemd.service and enable it: /etc/systemd/system/lowbatt.service [Unit] Description=Low Battery Auto-Suspend [Service] Type=simple RestartSec=60 Restart=always ExecStart=/usr/local/bin/lowbattcheck.sh [Install] WantedBy=multi-user.target sudo systemctl start lowbatt.service Now you have a 100% working auto-suspend for your laptop when battery capacity is = or lower than 5% Of course you can choice different percentage as well as replace systemctl suspend with systemctl hibernate, hybrid-sleep, if you prefer. Cheers, -- Marco Calistri Linux version : openSUSE Tumbleweed 20170830 Kernel: 4.12.10-3.gd79ffeb-default - Cinnamon 3.4.6 -- Marco Calistri Linux version : openSUSE Tumbleweed 20170830 Kernel: 4.12.10-3.gd79ffeb-default - Cinnamon 3.4.6 N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
![](https://seccdn.libravatar.org/avatar/45bf5eef0471996074efa055ea252116.jpg?s=120&d=mm&r=g)
El 03-09-2017 a las 16:59, Marco Calistri escribió: if
the abandon of pm-utils,
which was really broken to begin with.. systemd which does not handle your usecase.. or kernel if systemctl suspend works then kernel not to blame either.. hint, hint .systemctl suspend is the exact equivalent to echo mem > /sys/power/state or whatsoever, the fact is
that nothing seems working anymore now also by attempting to reconfigure DE power managers.
What is the problem with DE power managers.. which one are you using and what specifically are the results ? maybe there is a problem with them or with upower..hard to tell.. you are not giving us any evidence to draw a reasonable hypothesis of what might be broken. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/9f2f2d6d8b992b9993de56518908bde2.jpg?s=120&d=mm&r=g)
Il 04/09/2017 09:49, Cristian Rodríguez ha scritto:
El 03-09-2017 a las 16:59, Marco Calistri escribió:
if
the abandon of pm-utils,
which was really broken to begin with..
systemd
which does not handle your usecase..
or kernel
if systemctl suspend works then kernel not to blame either.. hint, hint .systemctl suspend is the exact equivalent to
echo mem > /sys/power/state
or whatsoever, the fact is
that nothing seems working anymore now also by attempting to reconfigure DE power managers.
What is the problem with DE power managers.. which one are you using and what specifically are the results ? maybe there is a problem with them or with upower..hard to tell.. you are not giving us any evidence to draw a reasonable hypothesis of what might be broken.
Well, honestly I've not reported anymore to Bugzilla since long time now. My last bug report neither received a single feedback, may be due my fault in being not compliant or even having not filled a detailed description, I don't know. But I'm sure to not to be the only one suffering with a non working suspend/hibernate on laptop here on Tumbleweed (tested on Gnome, XFCE and Cinnamon) and probably there (other Linux flavors). I say this because after I Googled looking for this matter, I found many users with exactly the same issue. For the Ask-Ubuntu forum there are plenty of discussion on this matter with suggestion and work-around, while I've found just few for openSUSE, this is another fact which difficult a bit the resolution of a eventual problem for us users of TW. Now I have resolved my problem just by adding some very basic scripts and I hope that someone else could use it to resolve similar issues. Of course I hope that openSUSE Tumbleweed will be working out of the box without such additional scripts in the future, but currently and at least for me it doesn't. -- TThheerree''ss aann EEcchhoo iinn hheerree. N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
![](https://seccdn.libravatar.org/avatar/ed90d0132a4f59f2d3a1cf82a1b70915.jpg?s=120&d=mm&r=g)
On 04.09.2017 20:17, Marco Calistri wrote:
But I'm sure to not to be the only one suffering with a non working suspend/hibernate on laptop here on Tumbleweed (tested on Gnome, XFCE and Cinnamon)
xfce4-power-manager low battery suspend definitely works for me here. I know it, because I hate it when this happens, and because you can only set it to "1% left", not "0% left". And 1% would still run for many minutes ;-) In your case, it not working in all DEs is more likely a problem with the battery driver or such, not sending events on capacity change and thus needing polling which might be not working correctly (I have no idea if this might be broken or not, my batteries are sending proper events) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/5b748275c3dbb1ceee18ed554486547d.jpg?s=120&d=mm&r=g)
On Wednesday 2017-09-06 10:11, Stefan Seyfried wrote:
On 04.09.2017 20:17, Marco Calistri wrote:
But I'm sure to not to be the only one suffering with a non working suspend/hibernate on laptop here on Tumbleweed (tested on Gnome, XFCE and Cinnamon)
xfce4-power-manager low battery suspend definitely works for me here.
I know it, because I hate it when this happens, and because you can only set it to "1% left", not "0% left". And 1% would still run for many minutes ;-)
Of course, that always depends on the size of the battery and the current CPU usage. When knowingly on the run, I don't do cpu-intensive stuff. But at the desk, that notification is a reminder that there is/was a cpuhog running and that I am (unscheduledly) not on AC :-p -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
![](https://seccdn.libravatar.org/avatar/9f2f2d6d8b992b9993de56518908bde2.jpg?s=120&d=mm&r=g)
Il 06/09/2017 05:11, Stefan Seyfried ha scritto:
On 04.09.2017 20:17, Marco Calistri wrote:
But I'm sure to not to be the only one suffering with a non working suspend/hibernate on laptop here on Tumbleweed (tested on Gnome, XFCE and Cinnamon)
xfce4-power-manager low battery suspend definitely works for me here.
I know it, because I hate it when this happens, and because you can only set it to "1% left", not "0% left". And 1% would still run for many minutes ;-)
In your case, it not working in all DEs is more likely a problem with the battery driver or such, not sending events on capacity change and thus needing polling which might be not working correctly (I have no idea if this might be broken or not, my batteries are sending proper events)
Thanks for your feedback Stefan, I tried to adjust the power-managers of all the DE I've installed on my TW and no one worked. My battery is old and it lost much of its factory charge but suspend works quite well on Windows 10 which I use in dual boot with TW and also from the changes I see into the files under /sys/class/power_supply/BAT1/ I understand that some sort of events are being still produced. In any case now I'm satisfied with my workaround the abrupt powering off is not healthy for HDD and batteries so to me this was an urgent problem to resolve. Cheers, -- Marco Calistri
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-09-06 18:00, Marco Calistri wrote:
In any case now I'm satisfied with my workaround the abrupt powering off is not healthy for HDD and batteries so to me this was an urgent problem to resolve.
But your method I think impedes the hard disk (if it is rotating type) to spin down. It is Ok on static type. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
![](https://seccdn.libravatar.org/avatar/9f2f2d6d8b992b9993de56518908bde2.jpg?s=120&d=mm&r=g)
Il 06/09/2017 13:46, Carlos E. R. ha scritto:
On 2017-09-06 18:00, Marco Calistri wrote:
In any case now I'm satisfied with my workaround the abrupt powering off is not healthy for HDD and batteries so to me this was an urgent problem to resolve.
But your method I think impedes the hard disk (if it is rotating type) to spin down. It is Ok on static type.
Yes, I've rotating (not SSD) HDD but my solution (suspend) I think is better than having a brutal shutdown like it was before out-of-the-box. Beside this I can switch in case I wish, between the three option available with systemctl: a) /usr/bin/systemctl suspend b) /usr/bin/systemctl hibernate c) /usr/bin/systemctl hibrid-sleep Cheers, -- TThheerree''ss aann EEcchhoo iinn hheerree. N�����r��y隊Z)z{.���r�+�맲��r��z�^�ˬz��N�(�֜��^� ޭ隊Z)z{.���r�+��0�����Ǩ�
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
On 2017-09-03 21:59, Marco Calistri wrote:
Hello,
During time I lost the benefits of having a working automatic suspend or hibernate function on my laptop for a certain level of low battery percentage.
...
So I decided to Google and finally I found a perfectly working alternative; I just tested on my Tumbleweed and it works perfectly.
...
1) put this script in your /usr/local/bin and set execution permission:
/usr/local/binlowbattcheck.sh
Probably /usr/local/sbin would be more appropriate. ...
It starts _only_ if your power supply is not plugged and if the battery capacity goes below 5%
2) create this systemd.service and enable it:
/etc/systemd/system/lowbatt.service
[Unit] Description=Low Battery Auto-Suspend
[Service] Type=simple RestartSec=60 Restart=always ExecStart=/usr/local/bin/lowbattcheck.sh
[Install] WantedBy=multi-user.target
sudo systemctl start lowbatt.service
There is a catch. This thing just runs a script every minute, similar to a cron job. It will cause the hard disk to be used once per minute, so the disk will never go to sleep, will keep rotating full time. It would be perhaps better a script that does the test on its own, looping every minute, always loaded. And probably better if it is a binary.
Now you have a 100% working auto-suspend for your laptop when battery capacity is = or lower than 5%
Of course you can choice different percentage as well as replace systemctl suspend with systemctl hibernate, hybrid-sleep, if you prefer.
I have found that these are not reliable. Some times the procedure aborts, but the screensaver may have kicked in so you never know that it failed unless you wonder and look. Other times the procedure takes minutes to complete, doing I don't know what. Both are dangerous situations with a low battery. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
participants (5)
-
Carlos E. R.
-
Cristian Rodríguez
-
Jan Engelhardt
-
Marco Calistri
-
Stefan Seyfried