How to run systemd user service to trigger on sleep (aka. suspend, hibernate)?

Question

Based on various sources I have cobbled together ~/.config/systemd/user/screenlock.service:

[Unit]
Description=Lock X session
Before=sleep.target

[Service]
Environment=DISPLAY=:0
ExecStart=/usr/bin/xautolock -locknow

[Install]
WantedBy=sleep.target

I've enabled it using systemctl --user enable screenlock.service. But after rebooting, logging in, suspending and resuming (tested both with systemctl suspend and by closing the lid) the screen is not locked and there is nothing in journalctl --user-unit screenlock.service. What am I doing wrong?

Running DISPLAY=:0 /usr/bin/xautolock -locknow locks the screen as expected.

$ systemctl --version
systemd 215
+PAM -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR
$ awesome --version
awesome v3.5.5 (Kansas City Shuffle)
 • Build: Apr 11 2014 09:36:33 for x86_64 by gcc version 4.8.2 (nobody@)
 • Compiled against Lua 5.2.3 (running with Lua 5.2)
 • D-Bus support: ✔
$ slim -v
slim version 1.3.6

If I run systemctl --user start screenlock.service the screen locks immediately and I get a log message in journalctl --user-unit screenlock.service, so ExecStart clearly is correct.

Relevant .xinitrc section:

xautolock -locker slock &

Creating a system service with the same file works (that is, slock is active when resuming):

# ln -s "${HOME}/.config/systemd/user/screenlock.service" /usr/lib/systemd/system/screenlock.service
# systemctl enable screenlock.service
$ systemctl suspend

But I do not want to add a user-specific file outside $HOME for several reasons:

• User services should be clearly separated from system services
• User services should be controlled without using superuser privileges
• Configuration should be easily version controlled

Solution

sleep.target is specific to system services. The reason is, sleep.target is not a magic target that automatically gets activated when going to sleep. It's just a regular target that puts the system to sleep – so the 'user' instances of course won't have an equivalent. (And unfortunately the 'user' instances currently have no way to depend on systemwide services.)

(That, and there's the whole "hardcoding $DISPLAY" business. Every time you hardcode session parameters in an OS that's based on the heavily multi-user/multi-seat Unix, root kills a kitten.)

So there are two good ways to do this (I suggest the 2nd one):

Method 1

Create a system service (or a systemd-sleep(8) hook) that makes systemd-logind broadcast the "lock all sessions" signal when the system goes to sleep:

ExecStart=/usr/bin/loginctl lock-sessions

Then, within your X11 session (i.e. from ~/.xinitrc), run something that reacts to the signal:

systemd-lock-handler slock &

xss-lock --ignore-sleep slock &

(GNOME, Cinnamon, KDE, Enlightenment already support this natively.)

Method 2

Within your X11 session, run something that directly watches for the system going to sleep, e.g. by hooking into systemd-logind's "inhibitors".

The aforementioned xss-lock actually does exactly that, even without the explicit "lock all" signal, so it is enough to have it running:

xss-lock slock &

It will run slock as soon as it sees systemd-logind preparing to suspend the computer.

Comments

[l0b0]

I'm using awesome as the window manager, and SLiM as the login manager. I'm not using a full desktop environment as defined by Arch, and Linux/awesome as the desktop environment as defined by Wikipedia. There doesn't seem to be anything like a "desktop manager" for Linux.

[jasonwryan]

User services are run outside of the session, so your session data is not available to them; you might be better off using a standard service file for this: at least to test anyway...

[l0b0]

@jasonwryan Surely I would see some sort of error message in the journal if the service had been triggered?

[jasonwryan]

I don't know: systemd-user is still very flaky; getting it to work as part of the session via the approach I outlined would help narrow down the issue; that's all I can suggest.

[Jakob Bennemann]

Though it is not a perfect solution (it would still need to be managed with root permissions), you can simply use /etc/systemd/system/ or $HOME/.local/systemd/system to avoid putting anything in /usr manually. As @jasonwryan mentioned, user sessions are still not considered production-quality; but they're getting closer.

[Pavel Šimerda]

Could you please elaborate a bit on the Enlightenment and others' native support? It's not clear what exactly they support natively from the answer.

[user1686]

@PavelŠimerda: The "lock session" signal from systemd-logind (...the entire section is about it...) Also, I was wrong, e19 doesn't actually support it.

[Pavel Šimerda]

Thanks for the info about E19. The answer still lacks explanation on what exactly Gnome and others support. Listening to systemd's D-Bus signal (even that's not written there) is one thing, what actions are done in reaction and what actions and how can the user configure to be done is another. Also there's no information on what systemd-lock-handler does and where it comes from.

[cgogolin]

This works beautifully under Debian testing. Thanks for posting. It is quite disappointing that systemd does not allow user services to depend on systems services...

[user1686]

@cgogolin: Well, it's not exactly trivial to implement either.

[Rolf]

Thank you very much, awesome solution! I don't always have an X session running and hate when this is assumed. I was hoping for a simple command to signal "userland systemd" and have services launch upon these "events" - since we can't access system targets from there. Anyway your solution is lean enough.

[Rolf]

In essence, some services (eg: the screen locker) need to run as, or be aware of the user who triggered them. This information gets lost in systemd. One downside of your solution is that there is no way to inhibit sleep until the locker has properly loaded.

[Rolf]

I tried to launch systemd_lock_handler from within a systemd --user service, and it complains about $XDG_SESSION_ID not being set. Is there any way around that?