Difference between revisions of "Talk:Laptop"

From ArchWiki
Jump to: navigation, search
(Remove closed discussions.)
m (RUN+="" won't work reliably: oops...)
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
==Other tweaks ==
 
No explanations with these tweaks? What do these do? Is linking to the source enough or should we describe what we're doing in detail? I'm never too comfortable with "do this" type instructions without a "this is why" explanations.--[[User:Multiphrenic|Multiphrenic]] 09:05, 27 April 2011 (EDT)
 
 
 
==Udev Rule to Suspend System==
 
==Udev Rule to Suspend System==
 
The udev rule could be edited to run a script that does polls the battery's capacity at regular interval when it's status changes to Discharging:
 
The udev rule could be edited to run a script that does polls the battery's capacity at regular interval when it's status changes to Discharging:
Line 7: Line 4:
 
  SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", <s>ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend</s> RUN+="/script/to/poll/battery/and/suspend/system.sh"
 
  SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", <s>ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend</s> RUN+="/script/to/poll/battery/and/suspend/system.sh"
 
There may also be a uevent that fires when the battery reaches an alarm state (when /sys/class/power_supply/BAT*/alarm is reached or changes).  I have not tested this on my own system yet or figured out just how that file works yet. [[User:Ego.abyssi|Ego.abyssi]] ([[User talk:Ego.abyssi|talk]]) 23:32, 3 March 2013 (UTC)
 
There may also be a uevent that fires when the battery reaches an alarm state (when /sys/class/power_supply/BAT*/alarm is reached or changes).  I have not tested this on my own system yet or figured out just how that file works yet. [[User:Ego.abyssi|Ego.abyssi]] ([[User talk:Ego.abyssi|talk]]) 23:32, 3 March 2013 (UTC)
 +
 +
:Strange, on my system battery sends "change" uevent each time battery is charged or discharged by 1%, so rule works perfectly and polling is an overcomplication.
 +
:--[[User:Eruditorum|Eruditorum]] ([[User talk:Eruditorum|talk]]) 06:48, 30 March 2013 (UTC)
 +
 +
::Hmm...  Well, if it works for you, then it must be something peculiar with my specific system.  In which case, yes, polling would be a needless complication.  I'll have to give it a look and see what the dillyo is. [[User:Ego.abyssi|Ego.abyssi]] ([[User talk:Ego.abyssi|talk]]) 05:58, 16 May 2013 (UTC)
 +
 +
:::On my system, acpi sends only adapter online/offline events, no ''changed-battery-level'', so the only solution is a daemon polling the battery level every minute or so... -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 16:42, 6 June 2013 (UTC)
 +
 +
== RUN+="<command>" won't work reliably ==
 +
 +
In the example:
 +
 +
{{hc|/etc/udev/rules.d/lowbat.rules|<nowiki>
 +
# Suspend the system when battery level drops to 2%
 +
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend"
 +
</nowiki>}}
 +
 +
{{bc|<nowiki>
 +
RUN
 +
...
 +
Starting daemons or other long running processes is not appropriate for
 +
udev; the forked processes, detached or not, will be unconditionally killed
 +
after the event handling has finished.
 +
</nowiki>}}
 +
 +
There's no garantee that systemctl will finish execution. Its possible to use {{ic|ENV{SYSTEMD_WANTS}&#61;"systemd-suspend.service"}} but I have not personally tested this. All these udev rules should be reworked to trigger one-shot systemd services ideally, which also brings along all the benefits of have systemd units (logging, debugging, etc).
 +
 +
-- [[User:Simongmzlj|Simongmzlj]]
 +
 +
:First of all, {{ic|1=RUN+=}} is not deprecated. Missing features do not predicate deprecation. I've removed the accuracy note from the page: [https://wiki.archlinux.org/index.php?title=Laptop&diff=276707&oldid=276704].
 +
:The {{ic|1=ENV{SYSTEMD_WANTS}="suspend.target"}} should be used ideally, but it has to be combined with {{ic|1=TAG+="systemd"}}.
 +
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:38, 26 September 2013 (UTC)

Revision as of 19:39, 26 September 2013

Udev Rule to Suspend System

The udev rule could be edited to run a script that does polls the battery's capacity at regular interval when it's status changes to Discharging:

## SLEEP IF BATTERY IS LOW
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend RUN+="/script/to/poll/battery/and/suspend/system.sh"

There may also be a uevent that fires when the battery reaches an alarm state (when /sys/class/power_supply/BAT*/alarm is reached or changes). I have not tested this on my own system yet or figured out just how that file works yet. Ego.abyssi (talk) 23:32, 3 March 2013 (UTC)

Strange, on my system battery sends "change" uevent each time battery is charged or discharged by 1%, so rule works perfectly and polling is an overcomplication.
--Eruditorum (talk) 06:48, 30 March 2013 (UTC)
Hmm... Well, if it works for you, then it must be something peculiar with my specific system. In which case, yes, polling would be a needless complication. I'll have to give it a look and see what the dillyo is. Ego.abyssi (talk) 05:58, 16 May 2013 (UTC)
On my system, acpi sends only adapter online/offline events, no changed-battery-level, so the only solution is a daemon polling the battery level every minute or so... -- Lahwaacz (talk) 16:42, 6 June 2013 (UTC)

RUN+="<command>" won't work reliably

In the example:

/etc/udev/rules.d/lowbat.rules
# Suspend the system when battery level drops to 2%
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend"
RUN
...
Starting daemons or other long running processes is not appropriate for
udev; the forked processes, detached or not, will be unconditionally killed
after the event handling has finished.

There's no garantee that systemctl will finish execution. Its possible to use ENV{SYSTEMD_WANTS}="systemd-suspend.service" but I have not personally tested this. All these udev rules should be reworked to trigger one-shot systemd services ideally, which also brings along all the benefits of have systemd units (logging, debugging, etc).

-- Simongmzlj

First of all, RUN+= is not deprecated. Missing features do not predicate deprecation. I've removed the accuracy note from the page: [1].
The ENV{SYSTEMD_WANTS}="suspend.target" should be used ideally, but it has to be combined with TAG+="systemd".
-- Lahwaacz (talk) 19:38, 26 September 2013 (UTC)