Difference between revisions of "Talk:Laptop"

From ArchWiki
Jump to: navigation, search
m (RUN+="" won't work reliably: oops...)
(Udev Rule to Suspend System: fix link)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
==Udev Rule to Suspend System==
+
==<s>Udev Rule to Suspend System</s>==
 
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:
 
  ## SLEEP IF BATTERY IS LOW
 
  ## SLEEP IF BATTERY IS LOW
Line 11: Line 11:
  
 
:::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)
 
:::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)
 +
 +
::::As some systems have no acpi events at all (like the [[Lenovo ThinkPad X201|X201]] after a suspend cycle), crontab is better suited in this case. Added with [https://wiki.archlinux.org/index.php?title=Laptop&type=revision&diff=427832&oldid=417028], closing. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:46, 25 March 2016 (UTC)
  
 
== RUN+="<command>" won't work reliably ==
 
== RUN+="<command>" won't work reliably ==
Line 36: Line 38:
 
: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 20:47, 25 March 2016

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)
As some systems have no acpi events at all (like the X201 after a suspend cycle), crontab is better suited in this case. Added with [1], closing. -- Alad (talk) 20:46, 25 March 2016 (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: [2].
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)