YubiKey の削除時に xsecurelock をトリガーしようとしています。これは次のように実行されます。
ファイル：90-yubikey.rules：
ACTION="remove", SUBSYSTEM="usb", ATTRS{idVendor}=="1050", RUN+="/bin/xsecurelock"
その後、 を実行しsudo udev --reload、yubikey を取り外しましたが、何も起こりませんでした。
udevadm --propertyudev がデバイスの削除を検出し、idVendor が実際に 1050 であることを確認しました。
注: 実行するとルートとしてロックされ、理想的ではないことは承知しています/bin/xsecurelockが、ルールがトリガーされたら修正します :)
答え1
ATTRS{} は udev プロパティとは一致しません。完全に異なる sysfs 属性と一致します。使用されるたびに、/sys の下のデバイスのサブディレクトリからファイルを直接読み取ります。Yubikey を取り外すと、そのサブディレクトリは存在しなくなります。
'udevadm monitor --property' に表示される値は udev データベースに保存され、削除時に ENV{} または ENVS{} を使用して照合できます。そのため、 の代わりにATTRS{idVendor}を使用する必要がありますENV{ID_VENDOR_ID}。
それ以外にも、udev ルールを記述するためのルールがあります。
- Udev ルールでは長時間実行されるプロセスを開始できません。'RUN' はデバイスを準備するヘルパー ツール用であるため、すべてのデバイス処理はそれが終了するまで待機します。
- Udev ルールは X サーバーのアドレスを持っていないため、X11 関連のものを何も実行できません。
一般的な回避策は、RUN+="systemctl ..."プログラムを systemd サービスとして起動することです。
あなたのケースで最も適切な方法は、RUN+="loginctl lock-sessions"デスクトップ環境 (または xss-lock) を使用してスクリーンセーバーの起動を処理させることです。