web-dev-qa-db-ja.com

udevルールでENV {SYSTEMD_USER_WANTS} =を使用するにはどうすればよいですか？

ユーザーレベルのsystemdでdocked.targetを設定したいと思います。アイデアは、いくつかのサービスを実行して外部ディスプレイを構成することです。

私は現在これを私のルールとして持っています：

SUBSYSTEM=="usb", ACTION=="add", ENV{ID_VENDOR}=="17ef", ENV{ID_MODEL}=="100a", SYMLINK+="tp_mini_dock", TAG+="systemd", ENV{SYSTEMD_USER_WANTS}="docked.target"

ルールは問題なく検出されます（ドッキングするとdev-tp_mini_dock.deviceが表示されます）。

次に、これを~/.config/systemd/user/docked.targetに入れます（運が悪か​​ったので/etc/systemd/userも試しました）：

[Unit]
Description=Docked to ThinkPad Mini Dock
BindTo=dev-tp_mini_dock.device

しかし、ドッキングしてもこれは開始されません。ただし、ドッキング中に手動でdocked.targetを起動すると、ドッキングを解除すると期待どおりに停止します。

ただし、ENV{SYSTEMD_WANTS}="docked.target"を使用してファイルを/etc/systemd/system/docked.targetに配置すると、ドッキング時にターゲットが期待どおりに起動します。問題は、ユーザーレベルのインスタンスがシステムレベルのサービス/ターゲットを認識していないことです。

何かご意見は？私はネットの周りで他のいくつかの質問を見ました、そして1つは私のものとほとんど同じです： https://bbs.archlinux.org/viewtopic.php?pid=1600019

linuxsystemdudev
4
aiguofer

SYSTEMD_USER_WANTSをMANAGER_USER_WANTSに置き換えてみてください。この名前の変更について100％確信はありませんが、少なくともsystemd-226では、ソースにSYSTEMD_USER_WANTSについての言及がなく、MANAGER_USER_WANTSに置き換えられているようです。少なくとも、同じような場合にはうまくいきました。

3
Pavel Procopiuc

ENV{SYSTEMD_USER_WANTS}がどのように機能するかはまだわかりませんが、 このブログ を読んだ後、特定の問題を解決することができました。

デバイスへの依存関係としてターゲットをインストールできることがわかりました。ユニットファイル~/.config/systemd/user/docked.targetを次のように変更しました。

[Unit]
Description=Docked to ThinkPad Mini Dock
BindsTo=dev-tp_mini_dock.device
After=dev-tp_mini_dock.device

[Install]
WantedBy=dev-tp_mini_dock.device

そして私のudevルールは：

SUBSYSTEM=="usb", ACTION=="add", ENV{ID_VENDOR}=="17ef", ENV{ID_MODEL}=="100a", SYMLINK+="tp_mini_dock", TAG+="systemd"

次に、systemctl --user enable docked.targetで有効にします。

これで、ドッキングすると、udevルールがsystemdデバイスを作成し、それがターゲットを起動します。次に、BindsToオプションは、デバイスが消えたとき（プラグが抜かれたとき）にターゲットが停止することを確認します。

ドックがすでに接続されている状態でログインしたときにこれを機能させるには、無意味な魔法をかける必要がありました。default.targetをWantedByとAfterに追加するだけで十分だと想像できます。 ...ブログを書いた後、ブログへのリンクを追加します。

2
aiguofer

男...その問題は私も病気にした、なんてバグだ！

私の場合、HDMI（モニターホットプラグ）イベントを聞きたかったのですが、この問題を回避する方法を見つけました。このudevが、この名前またはその名前でサービスを開始したことをどういうわけか知っていて、再度実行することを拒否した場合は、毎回新しいサービスを開始すると信じ込ませましょう。対応するudevイベントに注目：

UDEV  [19214.534185] change   /devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0 (drm)
ACTION=change
DEVLINKS=/dev/dri/by-path/pci-0000:01:00.0-card
DEVNAME=/dev/dri/card0
DEVPATH=/devices/pci0000:00/0000:00:01.0/0000:01:00.0/drm/card0
DEVTYPE=drm_minor
HOTPLUG=1
ID_FOR_SEAT=drm-pci-0000_01_00_0
ID_PATH=pci-0000:01:00.0
ID_PATH_TAG=pci-0000_01_00_0
MAJOR=226
MINOR=0
SEQNUM=3364
SUBSYSTEM=drm
USEC_INITIALIZED=3280572

SEQNUMに注目してください。それは新しいイベントごとに変化しており、まさにそれが私たちが望んでいることです。

ACTION=="change", SUBSYSTEM=="drm", ENV{HOTPLUG}=="1", ENV{SYSTEMD_USER_WANTS}+="monitor-hotplug@$env{SEQNUM}.service", TAG+="systemd"

~/.config/systemd/user/[email protected]でもチャームのように機能します。うまくいけば、あなたのイベントにもSEQNUMまたは同様のものがあります。

1
Alexander Shukaev