Na podstawie różnych źródeł zebrałem razem ~/.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
Włączyłem to za pomocą systemctl --user enable screenlock.service
. Ale po ponownym uruchomieniu komputera, zalogowaniu się, zawieszeniu i wznowieniu (testowane zarówno z systemctl suspend
zamknięciem pokrywy, jak i przez nią) ekran nie jest zablokowany i nic w nim nie majournalctl --user-unit screenlock.service
. Co ja robię źle?
Uruchomienie DISPLAY=:0 /usr/bin/xautolock -locknow
blokuje ekran zgodnie z oczekiwaniami.
$ 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
Jeśli uruchomię systemctl --user start screenlock.service
ekran, blokuje się natychmiast i pojawia się komunikat logowania journalctl --user-unit screenlock.service
, więc ExecStart
jest to oczywiście poprawne.
xautolock -locker slock &
Utworzenie usługi systemowej z tymi samymi plikami działa (to znaczy slock
jest aktywne podczas wznawiania):
# ln -s "${HOME}/.config/systemd/user/screenlock.service" /usr/lib/systemd/system/screenlock.service
# systemctl enable screenlock.service
$ systemctl suspend
Ale nie chcę dodawać pliku specyficznego $HOME
dla użytkownika na zewnątrz z kilku powodów:
- Usługi użytkownika powinny być wyraźnie oddzielone od usług systemowych
- Usługi użytkowników powinny być kontrolowane bez korzystania z uprawnień administratora
- Konfiguracja powinna być łatwa do kontrolowania wersji
systemd-user
wciąż jest bardzo łuszcząca; sprawienie, by działało w ramach sesji za pomocą podejścia, które przedstawiłem, pomogłoby zawęzić problem; to wszystko, co mogę zasugerować./etc/systemd/system/
lub$HOME/.local/systemd/system
uniknąć/usr
ręcznego wprowadzania czegokolwiek . Jak wspomniano w @jasonwryan, sesje użytkowników nadal nie są uważane za jakość produkcyjną; ale zbliżają się.Odpowiedzi:
sleep.target
jest specyficzny dla usług systemowych. Powodem jest to, żesleep.target
nie jest magicznym celem, który aktywuje się automatycznie po zaśnięciu. Jest to zwykły cel, który uśpia system - więc wystąpienia użytkownika nie będą miały odpowiednika. (I niestety obecnie instancje „użytkownika” nie mają możliwości polegania na usługach ogólnosystemowych).(I jest cała ta sprawa „hardcoding $ DISPLAY”. Za każdym razem, gdy kodujesz parametry sesji w systemie operacyjnym opartym na uniksowym systemie z wieloma użytkownikami / wieloma użytkownikami, root zabija kotka.)
Są dwa dobre sposoby na zrobienie tego (sugeruję drugi):
Metoda 1
Utwórz usługę systemową (lub hak systemd-sleep (8)), który powoduje, że systemd-logind rozgłasza sygnał „zablokuj wszystkie sesje”, gdy system przejdzie w tryb uśpienia:
Następnie w ramach sesji X11 (tj. Z ~ / .xinitrc) uruchom coś, co reaguje na sygnał:
(GNOME, Cynamon, KDE,
Oświeceniejuż to obsługują natywnie).Metoda 2
W trakcie sesji X11 uruchom coś, co bezpośrednio obserwuje, czy system przechodzi w tryb uśpienia, np. Podłączając się do „inhibitorów” systemd-logind.
Wspomniana blokada xss faktycznie robi dokładnie to, nawet bez wyraźnego sygnału „zablokuj wszystko”, więc wystarczy, aby działała:
Uruchomi się,
slock
gdy tylko zobaczy, że systemd-logind przygotowuje się do zawieszenia komputera.źródło
xss-lock
znajduje się w AUR, więc nie trzeba go budować ręcznie.systemd-lock-handler
to skrypt w języku Python, który może to osiągnąć: https://github.com/grawity/code/blob/master/desktop/systemd-lock-handler .źródło