Basado en varias fuentes que he improvisado ~/.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
Lo he habilitado usando systemctl --user enable screenlock.service. Pero después de reiniciar, iniciar sesión, suspender y reanudar (probado con systemctl suspendy al cerrar la tapa) la pantalla no está bloqueada y no hay nada adentrojournalctl --user-unit screenlock.service . ¿Qué estoy haciendo mal?
La ejecución DISPLAY=:0 /usr/bin/xautolock -locknowbloquea la pantalla como se esperaba.
$ 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
Si ejecuto systemctl --user start screenlock.servicelos bloqueos de pantalla inmediatamente y recibo un mensaje de registro journalctl --user-unit screenlock.service, entonces ExecStartclaramente es correcto.
xautolock -locker slock &
Crear un servicio del sistema con el mismo archivo funciona (es decir, slockestá activo cuando se reanuda):
# ln -s "${HOME}/.config/systemd/user/screenlock.service" /usr/lib/systemd/system/screenlock.service
# systemctl enable screenlock.service
$ systemctl suspend
Pero no quiero agregar un archivo específico de usuario fuera $HOMEpor varias razones:
- Los servicios de usuario deben estar claramente separados de los servicios del sistema.
- Los servicios de usuario deben controlarse sin usar privilegios de superusuario
- La configuración debe ser fácilmente controlada por la versión

systemd-usersigue siendo muy escamoso; lograr que funcione como parte de la sesión a través del enfoque que describí ayudaría a reducir el problema; Eso es todo lo que puedo sugerir./etc/systemd/system/o$HOME/.local/systemd/systemevitar poner algo/usrmanualmente. Como @jasonwryan mencionó, las sesiones de usuario todavía no se consideran de calidad de producción; Pero se están acercando.Respuestas:
sleep.targetEs específico de los servicios del sistema. La razón essleep.targetque no es un objetivo mágico que se activa automáticamente cuando se va a dormir. Es solo un objetivo regular que pone el sistema en suspensión, por lo que las instancias de 'usuario', por supuesto, no tendrán un equivalente. (Y desafortunadamente, las instancias de 'usuario' actualmente no tienen forma de depender de los servicios de todo el sistema).(Eso, y está todo el negocio del "hardcoding $ DISPLAY". Cada vez que codifica los parámetros de sesión en un sistema operativo que se basa en Unix multiusuario / multiusuario, la raíz mata a un gatito).
Entonces, hay dos buenas maneras de hacer esto (sugiero la segunda):
Método 1
Cree un servicio del sistema (o un enlace systemd-sleep (8)) que haga que systemd-logind difunda la señal de "bloquear todas las sesiones" cuando el sistema se suspenda:
Luego, dentro de su sesión X11 (es decir, desde ~ / .xinitrc), ejecute algo que reaccione a la señal:
(GNOME, Cinnamon, KDE,
Enlightenmentya lo admiten de forma nativa).Método 2
Dentro de su sesión X11, ejecute algo que vigile directamente que el sistema se vaya a dormir, por ejemplo, conectándose a los "inhibidores" de systemd-logind.
El mencionado xss-lock en realidad hace exactamente eso, incluso sin la señal explícita de "bloquear todo", por lo que es suficiente para que se ejecute:
Se ejecutará
slocktan pronto como vea systemd-logind preparándose para suspender la computadora.fuente
xss-lockestá en el AUR, por lo que no hay necesidad de construirlo manualmente.systemd-lock-handleres un script de Python que puede lograr esto: https://github.com/grawity/code/blob/master/desktop/systemd-lock-handler .fuente