Udevの紹介：デバイスイベントを管理するためのLinuxサブシステム

スクリプトがデバイスイベントによってトリガーされるためには、udevはどのような条件下でスクリプトを呼び出す必要があるかを知っている必要があります。実生活では、サムドライブは、その色、製造元、およびコンピューターに接続したばかりであるという事実によって識別できます。ただし、コンピュータには別の基準セットが必要です。

Udevは、シリアル番号、メーカー、さらにはベンダーIDと製品ID番号によってデバイスを識別します。これはudevスクリプトのライフスパンの初期段階であるため、可能な限り幅広く、非特定的で、包括的である必要があります。つまり、スクリプトをトリガーするために、最初にほぼすべての有効なudevイベントをキャッチする必要があります。

udevadmモニターを使用 コマンドを使用すると、udevをリアルタイムで利用して、さまざまなデバイスを接続したときに何が表示されるかを確認できます。ルートになって試してみてください。

$ su

# udevadm monitor

監視機能は、受信したイベントを次のように出力します：

• UDEV：ルール処理後にudevが送信するイベント
• カーネル：カーネルuevent

udevadmモニターを使用 実行中、サムドライブを接続し、あらゆる種類の情報が画面に表示されるのを確認します。イベントのタイプが追加であることに注意してください イベント。これは、必要なイベントの種類を特定するための良い方法です。

udevadmモニター コマンドは多くの優れた情報を提供しますが、コマンド udevadm info を使用すると、よりきれいなフォーマットで表示できます。 、サムドライブが現在 / devのどこにあるかを知っていると仮定します 木。そうでない場合は、サムドライブを取り外して再度接続し、すぐに次のコマンドを発行します。

$ su -c 'dmesg | tail | fgrep -i sd*'

そのコマンドがsdb：sdb1を返した場合 たとえば、カーネルがサムドライブに sdbを割り当てていることがわかります。 ラベル。

または、 lsblkを使用することもできます サイズやパーティションなど、システムに接続されているすべてのドライブを表示するコマンド。

ドライブがファイルシステム内のどこにあるかを確認したので、次のコマンドを使用して、そのデバイスに関するudev情報を表示できます。

# udevadm info -a -n /dev/sdb | less

これにより、多くの情報が返されます。今のところ、情報の最初のブロックに焦点を当てます。

あなたの仕事は、そのデバイスに最も固有のデバイスに関するudevのレポートの一部を選択し、それらの固有の属性が検出されたときにスクリプトをトリガーするようにudevに指示することです。

udevadm情報 （デバイスパスで指定された）デバイスに関するレポートを処理してから、親デバイスのチェーンを「ウォークアップ」します。見つかったすべてのデバイスについて、Key-Value形式を使用してすべての可能な属性を出力します。デバイスの属性と単一の親デバイスの属性に応じて一致するルールを作成できます。

looking at device '/devices/000:000/blah/blah//block/sdb':

  KERNEL=="sdb"

  SUBSYSTEM=="block"

  DRIVER==""

  ATTR{ro}=="0" 

  ATTR{size}=="125722368"

  ATTR{stat}==" 2765 1537 5393"

  ATTR{range}=="16"

  ATTR{discard\_alignment}=="0"

  ATTR{removable}=="1"

  ATTR{blah}=="blah"

udevルールには、1つの親デバイスからの1つの属性が含まれている必要があります。

親属性は、デバイスを最も基本的なレベルから説明するものです。たとえば、物理ポートに接続されているものなどです。 またはサイズのあるものです またはこれはリムーバブルデバイスです 。

sdbのカーネルラベル以降 サムドライブを接続する前に接続された他のドライブの数に応じて変更される可能性があります。これは、udevルールの最適な親属性ではありません。ただし、概念実証として機能するため、使用できます。さらに良い候補は、これが「ブロック」システムデバイスであることを識別するSUBSYSTEM属性です（これが lsblk の理由です） コマンドはデバイスを一覧表示します。

80-local.rulesというファイルを開きます /etc/udev/rules.d 次のコードを入力します：

SUBSYSTEM=="block", ACTION=="add", RUN+="/usr/local/bin/trigger.sh"

ファイルを保存し、テストサムドライブを取り外して、再起動します。

待って、再起動 Linuxマシンで？

理論的には、 udevadm control --reloadを発行するだけです。 、これはすべてのルールをロードする必要がありますが、ゲームのこの段階では、すべての変数を削除するのが最善です。 Udevは十分に複雑であり、構文エラーが原因でそのルールが機能しなかったのか、それとも再起動する必要があるのか​​、一晩中ベッドに横になりたくありません。したがって、POSIXプライドが何を示しているかに関係なく再起動してください。

システムがオンラインに戻ったら、テキストコンソール（Ctl + Alt + F3など）に切り替えて、サムドライブを接続します。最近のカーネルを実行している場合は、ドライブを接続すると、コンソールに大量の出力が表示される可能性があります。 実行できませんでした/などのエラーメッセージが表示された場合 usr /local/bin/trigger.sh 、おそらくスクリプトを実行可能にするのを忘れたでしょう。それ以外の場合は、デバイスが接続されているか、何らかのカーネルデバイスが割り当てられているかなどが表示されることを願っています。

さて、真実の瞬間：

$ cat /tmp/udev.log

Tue Oct 31 01:35:28 NZDT 2035

/tmp/udev.logから返されたごく最近の日付と時刻が表示された場合 、udevはスクリプトを正常にトリガーしました。

$ lsusb

Bus 001 Device 002: ID 8087:0024 Slacker Corp. Hub

Bus 002 Device 002: ID 8087:0024 Slacker Corp. Hub 

Bus 003 Device 005: ID 03f0:3307 TyCoon Corp. 

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 hub

Bus 001 Device 003: ID 13d3:5165 SBo Networks

SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", RUN+="/usr/local/bin/thumb.sh"

SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", SYMLINK+="safety%n"

SUBSYSTEM=="block", ATTRS{idVendor}=="03f0", ACTION=="add", RUN+="/usr/local/bin/trigger.sh"

#!/usr/bin/bash



mount /dev/safety1 /mnt/hd

sleep 2

rsync -az /mnt/hd/ /home/seth/backups/ && umount /dev/safety1