xss-lock、loginctl lock-sessions、xsecurelock が Arch 上で連携して動作しない

xss-lock、loginctl lock-sessions、xsecurelock が Arch 上で連携して動作しない

arch に xsecurelock がインストールされており、 を実行してセッションをロックできますxsecure lock。 ただし、 でロックを試行してloginctl lock-sessionも何も起こりません (エラーは発生せず、出力もロックも行われません)。

私が行った調査によると、loginctl lock-sessionおそらく を呼び出していると思われxss-lockますが、ロッカーとして xsecurelock を使用する必要があることを認識するように xss-lock を構成する方法がわかりません。

実行すると、xss-lockロッカーが指定されていないというエラーが表示され、実行がxss-lock xsecurelockハングします。

答え1

xss-lock xsecurelock を実行するとハングします。

はい、それが本来の目的です。

の全体的なポイントloginctl lock-session[s]は、走る直接何かをブロックするのではなく、デスクトップ セッション内で既に実行されているプログラムに「ロック」信号をブロードキャストします。つまり、デスクトップ環境に自分自身をロックするように指示することになります。(これにより、外部でロッカーを起動しようとしたときに発生する「環境変数が見つからない」という問題がすべてうまく回避されます。)

したがって、「xss-lock」は、システム レベルではなくセッション レベルでのみ、バックグラウンド プロセス (デーモン) として永続的に実行されることを意図しています。&バックグラウンドを使用して ~/.xprofile から起動することも、ウィンドウ マネージャーの「自動実行」設定から起動することもできます (ほとんどすべてのウィンドウ マネージャーに自動実行設定があります)。

たとえば、i3 を使用する場合は、exec xss-lock xsecurelock~/.i3/config に追加します。または、すべてを 'startx' を使用して起動する場合は、xss-lock xsecurelock &~/.xinitrc のどこかに追加します。

答え2

説明どおりここ xss-lockDPMS signalingトリガーするためにを待機するため、ハングします。ユーザー 1686 が言ったように、ハングしないようにするには、 または(使用するもの)&のコマンドの後にを配置する必要があります(そうしないと、セッション全体がハングする可能性があります)。~/.xinitrc~/.xprofilexss-lock

手動でロックしたい場合は、 を使用する意味はありません。端末からxss-lock直接使用することも、DE/WM に応じてこれをキーにバインドして使用することもできます。xsecurelock

したがって、たとえば非アクティブによる自動ロックに使用するのは理にかなっていますxss-lock。そのためには、私xsetが投稿したリンクに記載されているように使用する必要があります。これが私が設定した方法です (dm-tool lockセッションをロックするには LightDM のコマンドを使用します)。

~/.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 &

ターミナルから直接ロックしたい場合は、 を使用するdm-tool lockか、WM の設定でキーバインディングを設定して を呼び出すだけですdm-tool lock

ご覧のとおり、xss-lock非アクティブによるロック以外に使用方法はありません

関連情報