xss-lock, loginctl lock-sessions, xsecurelock funktionieren unter Arch nicht zusammen

xss-lock, loginctl lock-sessions, xsecurelock funktionieren unter Arch nicht zusammen

Ich habe xsecurelock auf Arch installiert und kann die Sitzung sperren, indem ich ausführe xsecure lock. Der Versuch, mit zu sperren loginctl lock-session, führt jedoch nichts aus (kein Fehler, nur keine Ausgabe und keine Sperrung).

Aus meinen Recherchen loginctl lock-sessiongeht hervor, dass es vermutlich aufruft xss-lock, aber ich weiß nicht, wie ich xss-lock konfigurieren muss, um zu wissen, dass es xsecurelock als Sperre verwenden soll.

Beim Ausführen xss-lockwird bemängelt, dass kein Locker angegeben wurde, und das Ausführen xss-lock xsecurelockhängt sich einfach auf.

Antwort1

Beim Ausführen von XSS-Lock bleibt xsecurelock einfach hängen.

Ja, das ist es, was es tun soll.

Der springende Punkt loginctl lock-session[s]ist, dass es nichtlaufennichts direkt; stattdessen sendet es ein „Lock“-Signal an Programme, die bereits in Ihrer Desktop-Sitzung laufen – und weist damit die Desktop-Umgebung im Grunde an, sich selbst zu sperren. (Dadurch werden alle Probleme mit „fehlenden Umgebungsvariablen“ vermieden, die beim Versuch auftreten würden, einen Locker extern zu starten.)

"xss-lock" soll also permanent als Hintergrundprozess laufen – ein Daemon, nur auf Sitzungsebene, nicht auf Systemebene. Sie können es aus Ihrem ~/.xprofile heraus starten, indem Sie es &als Hintergrund verwenden, oder Sie können es aus den "Autorun"-Einstellungen Ihres Fenstermanagers starten (fast alle WMs haben welche).

Wenn Sie beispielsweise i3 verwenden, fügen Sie es exec xss-lock xsecurelockzu ~/.i3/config hinzu. Wenn Sie alternativ alles mit „startx“ starten, fügen Sie es xss-lock xsecurelock &irgendwo in ~/.xinitrc hinzu.

Antwort2

Wie beschriebenHier xss-lockbleibt hängen, weil es wartet, DPMS signalingbis es ausgelöst wird. Wie Benutzer 1686 sagte, müssen Sie &nach dem Befehl in Ihrem ~/.xinitrcoder ~/.xprofile(was auch immer Sie verwenden) Folgendes einfügen, damit xss-lockes nicht hängen bleibt (sonst könnte Ihre gesamte Sitzung hängen bleiben).

Wenn Sie manuell sperren möchten, ist die Verwendung von nicht sinnvoll xss-lock. Sie können xsecurelockes je nach Ihrem DE/WM direkt von einem Terminal aus verwenden oder indem Sie es an einen Schlüssel binden.

Daher ist es sinnvoll, es xss-lockbeispielsweise für die automatische Sperrung aufgrund von Inaktivität zu verwenden. Dazu müssen Sie xsetes wie in dem von mir geposteten Link beschrieben verwenden. So habe ich es eingerichtet (ich verwende den dm-tool lockBefehl von LightDM, um die Sitzung zu sperren).

~/.xinitrc
# Some other things ...

xset s on
xset s 300 # Signal after 5 minutes / 300 seconds of inactivity
xss-lock dm-tool lock &
# Your's would be xss-lock xsecurelock &

Wenn ich direkt vom Terminal aus sperren möchte, verwende ich einfach dm-tool lockeine Tastenkombination zum Aufrufen oder lege sie in der Konfiguration meines WM fest dm-tool lock.

Wie Sie sehen, gibt es xss-lockaußer der Sperrung aufgrund von Inaktivität keinen Nutzen

verwandte Informationen