Come eseguire il servizio utente di systemd per attivarsi in modalità sospensione (ovvero sospensione, ibernazione)?


17

Sulla base di varie fonti ho messo insieme ~/.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

L'ho abilitato usando systemctl --user enable screenlock.service. Ma dopo il riavvio, il login, la sospensione e la ripresa (testati sia con systemctl suspendche chiudendo il coperchio) lo schermo non viene bloccato e non c'è nulla dentrojournalctl --user-unit screenlock.service . Che cosa sto facendo di sbagliato?

L'esecuzione DISPLAY=:0 /usr/bin/xautolock -locknowblocca lo schermo come previsto.

$ 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

Se systemctl --user start screenlock.serviceeseguo immediatamente i blocchi dello schermo e ottengo un messaggio di accesso journalctl --user-unit screenlock.service, ExecStartè chiaramente corretto.

.xinitrcSezione pertinente :

xautolock -locker slock &

La creazione di un servizio di sistema con lo stesso file funziona (vale a dire che slockè attiva quando si riprende):

# ln -s "${HOME}/.config/systemd/user/screenlock.service" /usr/lib/systemd/system/screenlock.service
# systemctl enable screenlock.service
$ systemctl suspend

Ma non voglio aggiungere un file specifico dell'utente all'esterno $HOMEper diversi motivi:

  • I servizi utente devono essere chiaramente separati dai servizi di sistema
  • I servizi utente devono essere controllati senza utilizzare i privilegi di superutente
  • La configurazione dovrebbe essere facilmente controllata dalla versione

Sto utilizzando impressionante come il window manager, e Slim come login manager. Non sto usando un ambiente desktop completo come definito da Arch e Linux / fantastico come ambiente desktop come definito da Wikipedia . Non sembra esserci niente come un "desktop manager" per Linux.
l0b0

I servizi utente vengono eseguiti al di fuori della sessione, quindi i dati della sessione non sono disponibili per loro; potresti stare meglio usando un file di servizio standard per questo: almeno per testare comunque ...
jasonwryan

@jasonwryan Sicuramente vedrei una sorta di messaggio di errore nel diario se il servizio fosse stato attivato?
l0b0

Non lo so: systemd-userè ancora molto traballante; farla funzionare come parte della sessione attraverso l'approccio che ho delineato contribuirebbe a restringere il problema; questo è tutto ciò che posso suggerire.
Jasonwryan,

Sebbene non sia una soluzione perfetta (dovrebbe comunque essere gestita con i permessi di root), puoi semplicemente usare /etc/systemd/system/o $HOME/.local/systemd/systemper evitare di inserire qualcosa /usrmanualmente. Come menzionato da @jasonwryan, le sessioni utente non sono ancora considerate di qualità produttiva; ma si stanno avvicinando.
HalosGhost

Risposte:


20

sleep.targetè specifico per i servizi di sistema. Il motivo è che sleep.targetnon è un bersaglio magico che si attiva automaticamente quando si va a dormire. È solo un obiettivo normale che mette il sistema in stand-by, quindi ovviamente le istanze "utente" non avranno un equivalente. (E sfortunatamente le istanze "utente" al momento non hanno modo di dipendere da servizi a livello di sistema.)

(Quello, e c'è l'intera attività di "hardcoding $ DISPLAY". Ogni volta che si codificano i parametri di sessione in un sistema operativo basato su Unix pesantemente multiutente / multi-sede, root uccide un gattino.)

Quindi ci sono due buoni modi per farlo (suggerisco il secondo):

Metodo 1

Creare un servizio di sistema (o un hook di systemd-sleep (8) che faccia trasmettere a systemd-logind il segnale "blocca tutte le sessioni" quando il sistema va in modalità di sospensione:

ExecStart=/usr/bin/loginctl lock-sessions

Quindi, all'interno della sessione X11 (ovvero da ~ / .xinitrc), esegui qualcosa che reagisce al segnale:

systemd-lock-handler slock &
xss-lock --ignore-sleep slock &

(GNOME, Cinnamon, KDE, Enlightenment lo supportano già in modo nativo.)

Metodo 2

Nella tua sessione X11, esegui qualcosa che controlla direttamente che il sistema vada in sospensione, ad esempio collegandosi agli "inibitori" di systemd-logind.

Il summenzionato xss-lock in realtà fa esattamente questo, anche senza il segnale esplicito "blocca tutto", quindi è sufficiente farlo funzionare:

xss-lock slock &

Verrà eseguito slocknon appena vede systemd-logind preparando a sospendere il computer.


Potresti per favore approfondire un po 'l'Illuminismo e il supporto nativo degli altri? Non è chiaro cosa sostengano esattamente nativamente dalla risposta.
Pavel Šimerda,

@ PavelŠimerda: il segnale di "blocco della sessione" da systemd-logind (... l'intera sezione è su di esso ...) Inoltre, ho sbagliato, e19 non lo supporta in realtà.
user1686,

Grazie per le informazioni su E19. La risposta manca ancora di spiegazioni su ciò che esattamente Gnome e altri supportano. Ascoltare il segnale D-Bus di systemd (anche se non è scritto lì) è una cosa, quali azioni vengono eseguite in reazione e quali azioni e in che modo l'utente può configurare per essere fatto è un'altra. Inoltre non ci sono informazioni su cosa fa systemd-lock-handler e da dove provenga.
Pavel Šimerda,

xss-lockè nell'AUR, quindi non è necessario crearlo manualmente.
l0b0

Funziona magnificamente con i test Debian. Grazie per la pubblicazione. È deludente che systemd non consenta ai servizi utente di dipendere dai servizi di sistema ...
cgogolin,

-1

systemd-lock-handlerè uno script Python che può ottenere questo risultato: https://github.com/grawity/code/blob/master/desktop/systemd-lock-handler .

#!/usr/bin/env python
# systemd-lock-handler -- proxy between systemd-logind's "Lock" signal and your
#   favourite screen lock command

from __future__ import print_function
import os, sys, dbus, dbus.mainloop.glib
from gi.repository import GLib

def trace(*args):
    global arg0
    print("%s:" % arg0, *args)

def setup_signal(signal_handler):
    global session_id
    bus = dbus.SystemBus()
    manager = bus.get_object("org.freedesktop.login1", "/org/freedesktop/login1")
    # yecch
    manager = dbus.Interface(manager, "org.freedesktop.login1.Manager")
    session_path = manager.GetSession(session_id)
    session = bus.get_object("org.freedesktop.login1", session_path)
    session.connect_to_signal("Lock", signal_handler)

def handler_dbus_fdo():
    trace("locking session using DBus")
    bus = dbus.SessionBus()
    screensaver = bus.get_object("org.freedesktop.ScreenSaver", "/ScreenSaver")
    screensaver.Lock()

def handler_external():
    global lock_command
    trace("locking session using %r" % lock_command[0])
    os.spawnvp(os.P_NOWAIT, lock_command[0], lock_command)

def main():
    global arg0, lock_command, session_id
    arg0 = sys.argv[0].split("/")[-1]
    lock_command = sys.argv[1:] or ["--dbus"]
    try:
        session_id = os.environ["XDG_SESSION_ID"]
    except KeyError:
        print("error: $XDG_SESSION_ID not set; are you using pam_systemd?",
            file=sys.stderr)
        sys.exit(1)
    dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
    if lock_command == ["--dbus"]:
        trace("using freedesktop.org DBus API")
        setup_signal(handler_dbus_fdo)
    else:
        trace("using external command %r" % lock_command[0])
        setup_signal(handler_external)
    trace("waiting for lock signals on session %s" % session_id)
    try:
        loop = GLib.MainLoop()
        loop.run()
    except KeyboardInterrupt:
        sys.exit(0)

main()
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.