Difference between revisions of "Talk:Laptop"
m (→RUN+="" won't work reliably: add missing signature) |
(→RUN+="" won't work reliably: re) |
||
Line 32: | Line 32: | ||
-- [[User:Simongmzlj|Simongmzlj]] | -- [[User:Simongmzlj|Simongmzlj]] | ||
+ | |||
+ | :First of all, {{ic|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|TAG+="systemd"}}. | ||
+ | :-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 19:38, 26 September 2013 (UTC) |
Revision as of 19:38, 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 suspendRUN+="/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)
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