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 suspend
y 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 -locknow
bloquea 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.service
los bloqueos de pantalla inmediatamente y recibo un mensaje de registro journalctl --user-unit screenlock.service
, entonces ExecStart
claramente es correcto.
xautolock -locker slock &
Crear un servicio del sistema con el mismo archivo funciona (es decir, slock
está 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 $HOME
por 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-user
sigue 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/system
evitar poner algo/usr
manualmente. Como @jasonwryan mencionó, las sesiones de usuario todavía no se consideran de calidad de producción; Pero se están acercando.Respuestas:
sleep.target
Es específico de los servicios del sistema. La razón essleep.target
que 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á
slock
tan pronto como vea systemd-logind preparándose para suspender la computadora.fuente
xss-lock
está en el AUR, por lo que no hay necesidad de construirlo manualmente.systemd-lock-handler
es un script de Python que puede lograr esto: https://github.com/grawity/code/blob/master/desktop/systemd-lock-handler .fuente