[opensuse-factory] upower useless on TW?
Hello, So my battery state went to 'critical' according to upower, a notification was displayed, and the system was shut down immediately. If upower cannot resolve the issue in any useful way I would prefer to use the system until it crashes. Apparently upower would hibernate the system (by default) if it deemed the feature available but for some reason it thinks my system cannot be hibernated. How does it determine this? Both upower(7) and upowerd(8) are stubs referencing a mailing list. Can we remove any dependencies on this abomination? Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 06.02.19 um 20:10 schrieb Michal Suchánek:
Hello,
So my battery state went to 'critical' according to upower, a notification was displayed, and the system was shut down immediately.
If upower cannot resolve the issue in any useful way I would prefer to use the system until it crashes.
Apparently upower would hibernate the system (by default) if it deemed the feature available but for some reason it thinks my system cannot be hibernated.
How does it determine this? Both upower(7) and upowerd(8) are stubs referencing a mailing list.
Upower probably just asks systemd-logind or whoever handles that. systemd-logind has some weird magic that makes it check free swap and then decide if hibernate can succeed. Unfortunately it does this wrong. E.g. I have 8G RAM and 2G Swap, and very often with firefox and thunderbird open, systemd will conclude I cannot hibernat *and not even try it*. "echo disk > /sys/power/state" will then hibernate just fine. Anyway. You can tweak the settings in /etc/UPower/UPower.conf, but I'm not sure if you can disable the action completely. If you are running a desktop environment, the settings from there should override the upower and systemd-logind settings.
Can we remove any dependencies on this abomination?
strolchi:~ # rpm -e --test upower error: Failed dependencies: upower is needed by (installed) gnome-power-manager-3.30.0-1.2.x86_64 upower is needed by (installed) xfce4-power-manager-1.6.1-2.3.x86_64 should be painless for you to remove it. -- 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
On Wed, 6 Feb 2019 20:23:09 +0100
Stefan Seyfried
Am 06.02.19 um 20:10 schrieb Michal Suchánek:
Hello,
So my battery state went to 'critical' according to upower, a notification was displayed, and the system was shut down immediately.
If upower cannot resolve the issue in any useful way I would prefer to use the system until it crashes.
Apparently upower would hibernate the system (by default) if it deemed the feature available but for some reason it thinks my system cannot be hibernated.
How does it determine this? Both upower(7) and upowerd(8) are stubs referencing a mailing list.
Upower probably just asks systemd-logind or whoever handles that.
systemd-logind has some weird magic that makes it check free swap and then decide if hibernate can succeed. Unfortunately it does this wrong. systemd ...
E.g. I have 8G RAM and 2G Swap, and very often with firefox and thunderbird open, systemd will conclude I cannot hibernat *and not even try it*. "echo disk > /sys/power/state" will then hibernate just fine.
Anyway. You can tweak the settings in /etc/UPower/UPower.conf, but I'm not sure if you can disable the action completely.
As far as the config file comments say you cannot do that, only select what is tried first.
If you are running a desktop environment, the settings from there should override the upower and systemd-logind settings.
I am running lxpanel.
Can we remove any dependencies on this abomination?
strolchi:~ # rpm -e --test upower error: Failed dependencies: upower is needed by (installed) gnome-power-manager-3.30.0-1.2.x86_64 upower is needed by (installed) xfce4-power-manager-1.6.1-2.3.x86_64
should be painless for you to remove it.
Not really: # zypper rm -u upower Loading repository data... Warning: No repositories defined. Operating only with the installed resolvables. Nothing can be installed. Reading installed packages... Resolving package dependencies... The following 24 packages are going to be REMOVED: enscript fate grantlee5 icoutils ispell ispell-american kde4-filesystem kdebase4-runtime kdebase4-workspace-libs kdelibs4 kdelibs4-branding-upstream kdelibs4-core kdialog kdialog-lang khelpcenter5 khelpcenter5-lang libctemplate3 libkactivities6 libpolkit-qt-1-1 libupower-glib3 libxapian30 upower upower-lang words 24 packages to remove. After the operation, 63.6 MiB will be freed. Continue? [y/n/...? shows all options] (y): ^C # rpm -e --test upower error: Failed dependencies: upower = 0.99.9 is needed by (installed) upower-lang-0.99.9-1.1.noarch upower is needed by (installed) kdelibs4-4.14.38-6.2.x86_64 Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/6/2019 11:10 AM, Michal Suchánek wrote:
Hello,
So my battery state went to 'critical' according to upower, a notification was displayed, and the system was shut down immediately.
If upower cannot resolve the issue in any useful way I would prefer to use the system until it crashes.
It can -- and it did. It saved probably 10-15% in the battery for you to maybe engage in critical access if you need to access it before you get to power. If you want to configure it to do something else, you probably need to tell it. It _may_ have tried other things first, like putting the system in lower power mode, or even going to sleep and keeping memory refreshed, but if power goes below some critical value, most default power management setting will try to gracefully shut down the computer so programs that can save state, will and so data in memory _can_ be written to disk (doesn't mean all apps are written well and do this, however). If you want it to do something like save state to disk (hibernate), then usually you need to pre-configure a hibernate file. On 2/6/2019 11:23 AM, Stefan Seyfried wrote:
E.g. I have 8G RAM and 2G Swap, and very often with firefox and thunderbird open, systemd will conclude I cannot hibernat *and not even try it*. "echo disk > /sys/power/state" will then hibernate just fine.
Hibernate usually copies active ram to a pre-allocated hibernation file -- I can't see it trying to allocate a hibernation file or partition when you ask it to hibernate -- it could, but too many things _could_ go wrong and if it is because of lower power, and the owner is away from where they might see error messages, what should it do? It could try going to sleep where power is shut off to almost everything except memory, but that may not be safe. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hibernate usually copies active ram to a pre-allocated hibernation file
https://doc.opensuse.org/documentation/leap/reference/html/ book.opensuse.reference/cha.power-mgmt.html says Leap hibernates to swap if swap is sufficiently big. A hibernation file is not mentioned. Of course, if swap is in heavy use already a dedicated hibernation file with the size of used RAM (minus gains from compression) is needed. https://en.opensuse.org/SDB:Suspend_to_disk is out-dated (last tested on openSUSE 11.3) and nothing with "s2disk" in the filename exists in /var or / etc on my Leap 15.0 laptop. Any pointers how to make sure hibernation is always possible? If there no longer is the possibility of a separate hibernation file (that cannot be claimed for swap space) how would one limit swap usage to swapsize-ramsize? Joachim -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2/13/2019 1:33 AM, Joachim Wagner wrote:
Hibernate usually copies active ram to a pre-allocated hibernation file
https://doc.opensuse.org/documentation/leap/reference/html/ book.opensuse.reference/cha.power-mgmt.html says Leap hibernates to swap if swap is sufficiently big. A hibernation file is not mentioned.
---- Well, if you have a swap that you don't use for swap...then sure. But if swap is full of swapped memory, where does that go when you hibernate? Oh...um -- yeah... v v v
Of course, if swap is in heavy use already a dedicated hibernation file with the size of used RAM (minus gains from compression) is needed.
--- Compression -- depends on how fast you want to go into swap I suppose. If you have 96G of memory just writing that to disk at 1GB/s will take a minute and a half. I wouldn't rely on compression for hiber, since if it doesn't compress well, though zero'd memory compresses pretty well. :-)
https://en.opensuse.org/SDB:Suspend_to_disk is out-dated (last tested on openSUSE 11.3) and nothing with "s2disk" in the filename exists in /var or / etc on my Leap 15.0 laptop.
Any pointers how to make sure hibernation is always possible? If there no longer is the possibility of a separate hibernation file (that cannot be claimed for swap space) how would one limit swap usage to swapsize-ramsize?
---- you can make more than one Swap file... Call one Hibernation? What Windows does is semi-smart(am hoping Linux would have similar). Since reading 96G(or writing) memory to disk (or less, or more) takes time, they have a hybrid sleep/hiberr where they prepare for hibernation, but really put the machine into sleep state, keeping the memory in memory -- that way if battery fails, you can restart state from hibernation file, but if battery lives -- then machine can almost restart in seconds (obviously, sleep and full hiber are also available). I measured my housemates desktop -- 48G, HexaCore -- 4W in hybrid -- not bad for a 10yr old design. BTW, if I yak about win -- its cuz I use both -- win as a desktop and linux as everything else. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Wed, 13 Feb 2019 01:08:27 -0800
L A Walsh
On 2/6/2019 11:10 AM, Michal Suchánek wrote:
Hello,
So my battery state went to 'critical' according to upower, a notification was displayed, and the system was shut down immediately.
If upower cannot resolve the issue in any useful way I would prefer to use the system until it crashes.
It can -- and it did. It saved probably 10-15% in the battery for you to maybe engage in critical access if you need to access it before you get to power.
No, it effectively crashed my system earlier. I cannot access the system when it's powered down.
If you want to configure it to do something else, you probably need to tell it.
There is no documentation other than comments in the configuration file. The comments only say that you can configure what it tries first but not exclude some action. And it is not even clear how it decides that eg. hibernation is not available. It certainly did not *try* hibernate because it would be quite easy to notice.
It _may_ have tried other things first, like putting the system in lower power mode, or even going to sleep and keeping memory refreshed, but if power goes below some critical value, most default power management setting will try to gracefully shut down the computer so programs that can save state, will and so data in memory _can_ be written to disk (doesn't mean all apps are written well and do this, however).
I don't know about any apps that write out data when they are killed. Only apps that write out data all the time in case the system crashes. Which means without upower I could use the system 10% longer with same effect.
If you want it to do something like save state to disk (hibernate), then usually you need to pre-configure a hibernate file.
I have a swap file. I understand that it might not always be possible to hibernate if much swap is in use. However, it is not useful shutting down the system. At all. If upower cannot be configured to not do that it's useless. It seems an update the kdelibs to not depend on upower was submitted so I can remove the abomination and be done with it. Thanks Michal -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Joachim Wagner
-
L A Walsh
-
Michal Suchánek
-
Stefan Seyfried