systemd-suspend.service

Issue #10 resolved
Link created an issue

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)

  1. Link 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 .

  2. Log in to comment