4

/etc/udev/rules.d/local.rulesにスクリプトを作成しました

SUBSYSTEM=="usb", SYSFS{idVendor=="b58e"}, SYSFS{idProduct=="9e84"}, ACTION=="add", RUN+="notify-send USB"

次に、udevをリロードします

 sudo udevadm control --reload-rules

サブシステム以外のすべてを削除して実行しようとしました。'+='の代わりに'='を実行してみましたが、SYSFSの代わりにATTRに疲れました。「sudoserviceudevrestart」と「sudoreloadudev」を試してみました。デバイスのプラグを抜いてから再度差し込むと、アクションが実行されません。名前を70-local.rulesに変更し、権限をa+xに変更してみました。「サブシステム」を「バス」に変更してみました。同じコマンドを持つ「/path/test.sh」にrunを設定してみました。

4

2 に答える 2

11

私は専門家ではなく、これは答えではありませんが、トリガーする適切な属性を特定するのに役立つ次の手順を見つけました。

  1. udevadm、、、lsusbまたはを使用してデバイスパスを見つけますusb-devices。私は通常lsusb、シェルのタブ補完を使用してガイドします。私の場合、パスは/dev/bus/usb/003/007です。
  2. udevadmルールを作成するためのデバイス属性を識別するために使用します。私の場合、を使用しudevadm info -a --attribute-walk --root --name=/dev/bus/usb/003/007ました。
  3. ルールを作成し、それがトリガーされていることを確認します。私の場合、デバイスの所有者をユーザー「stephen」に変更するだけで、を使用して動作しているかどうかを確認するのは非常に簡単ですls -l /dev/bus/usb/003/007。この場合の私のルールは次のようになりますSUBSYSTEM=="usb", ATTR{idVendor}=="18d1", OWNER="stephen"。ATTRSサブシステムが期待していなかったため、しばらくの間私を困惑させた同様のルールがATTRあります。そのため、属性をウォークすることをお勧めします。この後者の場合のルールは、 `SUBSYSTEM == "tty"、ATTRS {idVendor} == "0403"、ATTRS {idProduct} == "6001"、OWNER="stephen"になりました。

そして、もちろん、man udev常に役に立ちます。あなたが言ったように、あなたはあなたのルールが適切にトリガーされていることを特定するのに苦労するべきであり、私が最初のステップで行ったようにデバイスの所有権をすばやく変更するのが最善かもしれません。悪い属性やシンボリックリンクで問題が発生することがあります。

于 2012-07-03T02:04:07.440 に答える
3

アクションは実行されません

いいえ、アクションを実行します。問題は、udevの起動時に通知フレームワークが実行されていないため、通知の送信先がわからないことです。システムバスを介してDBusメッセージを送信し、代わりにユーザーデーモンにメッセージをキャッチして通知を送信させる必要があります。

于 2012-07-02T23:50:28.770 に答える