2

I have problem with Ubuntu 19.04. System doesn't shutdown in normal way when battery is low. When battery level drops to 3% laptop is turning off like I pulled out the battery.

4
  • Are you using tlp? Jun 8, 2019 at 18:35
  • How to check of system is using tlp?
    – QkiZ
    Jun 10, 2019 at 5:35
  • Use systemctl status tlp Jun 10, 2019 at 10:27
  • Unit tlp.service could not be found.
    – QkiZ
    Jun 10, 2019 at 18:30

1 Answer 1

3

Unless something has changed recently you should have this file: /etc/UPower/UPower.conf containing:

# Only the system vendor should modify this file, ordinary users
# should not have to change anything.

[UPower]

# Enable the Watts Up Pro device.
#
# The Watts Up Pro contains a generic FTDI USB device without a specific
# vendor and product ID. When we probe for WUP devices, we can cause
# the user to get a perplexing "Device or resource busy" error when
# attempting to use their non-WUP device.
#
# The generic FTDI device is known to also be used on:
#
# - Sparkfun FT232 breakout board
# - Parallax Propeller
#
# default=false
EnableWattsUpPro=false

# Don't poll the kernel for battery level changes.
#
# Some hardware will send us battery level changes through
# events, rather than us having to poll for it. This option
# allows disabling polling for hardware that sends out events.
#
# default=false
NoPollBatteries=false

# Do we ignore the lid state
#
# Some laptops are broken. The lid state is either inverted, or stuck
# on or off. We can't do much to fix these problems, but this is a way
# for users to make the laptop panel vanish, a state that might be used
# by a couple of user-space daemons. On Linux systems, see also
# logind.conf(5).
#
# default=false
IgnoreLid=false

# Policy for warnings and action based on battery levels
#
# Whether battery percentage based policy should be used. The default
# is to use the time left, change to true to use the percentage, which
# should work around broken firmwares. It is also more reliable than
# the time left (frantically saving all your files is going to use more
# battery than letting it rest for example).
# default=true
UsePercentageForPolicy=true

# When UsePercentageForPolicy is true, the levels at which UPower will
# consider the battery low, critical, or take action for the critical
# battery level.
#
# This will also be used for batteries which don't have time information
# such as that of peripherals.
#
# If any value is invalid, or not in descending order, the defaults
# will be used.
#
# Defaults:
# PercentageLow=10
# PercentageCritical=3
# PercentageAction=2
PercentageLow=10
PercentageCritical=3
PercentageAction=2

# When UsePercentageForPolicy is false, the time remaining at which UPower
# will consider the battery low, critical, or take action for the critical
# battery level.
#
# If any value is invalid, or not in descending order, the defaults
# will be used.
#
# Defaults:
# TimeLow=1200
# TimeCritical=300
# TimeAction=120
TimeLow=1200
TimeCritical=300
TimeAction=120

# The action to take when "TimeAction" or "PercentageAction" above has been
# reached for the batteries (UPS or laptop batteries) supplying the computer
#
# Possible values are:
# PowerOff
# Hibernate
# HybridSleep
#
# If HybridSleep isn't available, Hibernate will be used
# If Hibernate isn't available, PowerOff will be used
CriticalPowerAction=HybridSleep

When percentage is true (default), the lines:

PercentageLow=10
PercentageCritical=3
PercentageAction=2

Means at 10% remaining you are told battery is running low. At 3% remaining a critical warning is issued saying battery is about to die. At 2% remaining your machine shuts down.

When percentage is false, the lines:

TimeLow=1200
TimeCritical=300
TimeAction=120

Means at 1200 seconds (20 minutes) remaining you are told battery is running low. At 300 seconds (5 minutes) remaining a critical warning is issued saying battery is about to die. At 120 seconds (2 minutes) remaining your machine shuts down.

The configuration file settings should be duplicated in gsettings which you can confirm with:

$ gsettings list-recursively | grep plugins.power | grep time
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
org.gnome.settings-daemon.plugins.power sleep-inactive-battery-timeout 0
org.gnome.settings-daemon.plugins.power time-low 1200
org.gnome.settings-daemon.plugins.power time-action 120
org.gnome.settings-daemon.plugins.power time-critical 300
org.gnome.settings-daemon.plugins.power use-time-for-policy true

and with:

$ gsettings list-recursively | grep plugins.power | grep percentage
org.gnome.settings-daemon.plugins.power percentage-low 10
org.gnome.settings-daemon.plugins.power percentage-critical 3
org.gnome.settings-daemon.plugins.power percentage-action 2
4
  • thx, thats more clear for me. but why upower settings and gnome settings daemon should be duplicated?
    – QkiZ
    Jun 11, 2019 at 20:38
  • The Upower settings are stored permanently on disk. During boot the gnome settings are derived from that. Operationally applications access gnome settings for speed and ease of access. On power off gnome settings are lost. Jun 12, 2019 at 10:34
  • So you mean that if I perform a change in gsettings and not in Upower.conf, they will not be reflected in Upower.conf and thus they will get lost upon rebooting? I don't recall having such experience. May 22, 2021 at 10:43
  • @sancho.sReinstateMonicaCellio This is an old answer but to me it seems to say the opposite eg that changes to Upower.conf can be verified by displaying gsettings. May 22, 2021 at 13:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .