Difference between revisions of "Talk:Laptop"

From ArchWiki
Jump to: navigation, search
m (RUN+="" won't work reliably: oops...)
m (Udev Rule to Suspend System: removed closed discussion)
 
(3 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==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", <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)
 
 
: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 ==
 
== RUN+="<command>" won't work reliably ==
  
Line 36: Line 23:
 
:The {{ic|1=ENV{SYSTEMD_WANTS}="suspend.target"}} should be used ideally, but it has to be combined with {{ic|1=TAG+="systemd"}}.
 
: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)
 
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:38, 26 September 2013 (UTC)
 +
 +
::Isn't the point that systemctl may not finish executing - certainly may not finish quickly enough for udev's liking? It is a matter of what is suitable in a udev rule due to the nature of udev. --[[User:Margali|cfr]] ([[User talk:Margali|talk]]) 01:47, 8 November 2013 (UTC)

Latest revision as of 09:32, 4 June 2016

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)
Isn't the point that systemctl may not finish executing - certainly may not finish quickly enough for udev's liking? It is a matter of what is suitable in a udev rule due to the nature of udev. --cfr (talk) 01:47, 8 November 2013 (UTC)