☰

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

tag-icon • tag-icon linux systemd udev
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、ドッキング時にターゲットが期待どおりに起動します。問題は、ユーザー レベルのインスタンスがシステム レベルのサービス/ターゲットを認識しないことです。

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

答え1

まだ仕組みはわかりませんが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ブログを書いたらリンクを追加します。WantedByAfter

答え2

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

答え3

ああ...その問題は私もうんざりしました、なんてバグなのでしょう!

私の場合、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

関連情報