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.