Sur la base de diverses sources, j'ai bricolé ensemble ~/.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
Je l'ai activé en utilisant systemctl --user enable screenlock.service
. Mais après le redémarrage, la connexion, la suspension et la reprise (testé à la fois avec systemctl suspend
et en fermant le couvercle), l'écran n'est pas verrouillé et il n'y a rienjournalctl --user-unit screenlock.service
. Qu'est-ce que je fais mal?
L'exécution DISPLAY=:0 /usr/bin/xautolock -locknow
verrouille l'écran comme prévu.
$ 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 j'exécute systemctl --user start screenlock.service
les verrous d'écran immédiatement et que je reçois un message de connexion journalctl --user-unit screenlock.service
, c'est donc ExecStart
clairement correct.
xautolock -locker slock &
La création d'un service système avec le même fichier fonctionne (c'est-à-dire slock
est active lors de la reprise):
# ln -s "${HOME}/.config/systemd/user/screenlock.service" /usr/lib/systemd/system/screenlock.service
# systemctl enable screenlock.service
$ systemctl suspend
Mais je ne veux pas ajouter un fichier spécifique à l'utilisateur à l'extérieur $HOME
pour plusieurs raisons:
- Les services utilisateurs doivent être clairement séparés des services système
- Les services utilisateur doivent être contrôlés sans utiliser les privilèges de superutilisateur
- La configuration doit être facilement contrôlée par la version
systemd-user
est encore très feuilletée; le faire fonctionner dans le cadre de la session via l'approche que j'ai décrite aiderait à affiner le problème; c'est tout ce que je peux suggérer./etc/systemd/system/
ou$HOME/.local/systemd/system
éviter de mettre quoi que ce soit/usr
manuellement. Comme l'a mentionné @jasonwryan, les sessions utilisateur ne sont toujours pas considérées comme une qualité de production; mais ils se rapprochent.Réponses:
sleep.target
est spécifique aux services système. La raison en est que cesleep.target
n'est pas une cible magique qui s'active automatiquement en s'endormant. C'est juste une cible régulière qui met le système en veille - donc les instances «utilisateur» n'auront bien sûr pas d'équivalent. (Et malheureusement, les instances «utilisateur» n'ont actuellement aucun moyen de dépendre des services à l'échelle du système.)(Cela, et il y a toute l'activité "hardcoding $ DISPLAY". Chaque fois que vous codez en dur des paramètres de session dans un système d'exploitation basé sur Unix fortement multi-utilisateurs / multi-postes, root tue un chaton.)
Il y a donc deux bonnes façons de le faire (je suggère le 2ème):
Méthode 1
Créez un service système (ou un hook systemd-sleep (8)) qui fait que systemd-logind diffuse le signal "verrouiller toutes les sessions" lorsque le système se met en veille:
Ensuite, dans votre session X11 (c'est-à-dire à partir de ~ / .xinitrc), exécutez quelque chose qui réagit au signal:
(GNOME, Cinnamon, KDE,
Enlightenment lesupportent déjà nativement.)Méthode 2
Dans votre session X11, exécutez quelque chose qui surveille directement le système qui va se mettre en veille, par exemple en vous connectant aux "inhibiteurs" de systemd-logind.
Le xss-lock susmentionné fait exactement cela, même sans le signal explicite de «verrouiller tout», il suffit donc de le faire fonctionner:
Il s'exécutera
slock
dès qu'il verra systemd-logind se préparer à suspendre l'ordinateur.la source
xss-lock
est dans l'AUR, il n'est donc pas nécessaire de le construire manuellement.systemd-lock-handler
est un script Python qui peut accomplir cela: https://github.com/grawity/code/blob/master/desktop/systemd-lock-handler .la source