systemd-suspend.service
xss-lock doesn't appear to be aware that the system is going down when I run: systemctl start systemd-suspend.service
As best I can tell, this is the only way to get udev to trigger a suspend: SUBSYSTEM=="power_supply", KERNEL=="BAT0", ATTR{capacity}=="[0-6]", ATTR{status}=="Discharging", TAG+="systemd", ENV{SYSTEMD_WANTS}+="systemd-suspend.service"
(you can't use RUN because the way udev works, the 'process' gets terminated after a few seconds, immediately waking up the system if it managed to suspend).
Comments (3)
-
reporter -
reporter eh. The manpage says to never manually invoke systemd-suspend.service, always use systemctl suspend. Which is stupid. They designed an elaborate system of services with hooks and dependencies and everything neatly weaving together- and then neglect to use it! Creating instead a proprietary frontend. What the hell.
I got around this by writing my own oneshot service to exec systemctl suspend. It might interest you to look into why xss-lock wasn't working when using systemd-suspend.service (also, suspend.target), but I can't blame you for bad design in the upstream .
-
reporter - changed status to resolved
- Log in to comment
Without RUN, I cannot "systemctl suspend", which xss-lock does work with.