USBドライブが接続されたときに含まれるすべてのファイルシステムに対してUSBドライブを検索し、検出されたファイルシステムの種類に応じて操作を実行するカスタム機能を実装しようとしています。デバイスノードに対してudev
インスタンス化された「ワンショット」サービスをトリガーするために、ルールを「推奨」として作成しました。systemd
これにより、「すべてのマジック(TM)を実行します」シェルスクリプトが実行されます(プラットフォーム独立のため、コンパイルプログラムのオプションは考慮されません)。ここ)。
ACTION=="add", SUBSYSTEMS=="usb", SUBSYSTEM=="block", ENV{DEVTYPE}=="disk", RUN{program}="/bin/systemctl start usb-drive-manager@$devnode.service"
そして
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/local/bin/usb_drive_manager.sh attach %I
ExecStop=/usr/local/bin/usb_drive_manager.sh detach %I
シェルスクリプトは、ls /sys/.../sdX/sdX*
ドライブのデバイスパスで操作を実行してパーティションを見つけ、呼び出しによってそのパーティションに関する情報を照会します。
udevadm info /dev/sdXn
(n
パーティション番号はどこにありますか?)処理された各パーティションについて。
質問これはシェルスクリプトの「コールドプラグ」テスト中に機能しますが、スクリプトがルールでトリガされると機能しませんudev
。udev
運転する処理後の情報は次のとおりです。分割ドライブの情報はまだカーネルによって収集されていません。つまり、呼び出しはudevadm info
基本情報のみを返します。
P: /devices/.../block/sdb/sdb1
N: sdb1
E: DEVNAME=/dev/sdb1
E: DEVPATH=/devices/.../block/sdb/sdb1
E: DEVTYPE=partition
E: MAJOR=8
E: MINOR=17
E: SUBSYSTEM=block
そしてすべての関連情報、特に環境変数ID_FS_TYPE
はID_FS_LABEL
(まだ)失われます。イベントudevadm settle
の処理中に呼び出すのは悪い考えであり(助けにはならない)、呼び出しの間に眠っている0.5秒のポーリングループも機能しないため(情報が最終的に利用可能になるまで約1分かかります)。アクションが失われました。udev
udevadm info
残念ながらudev
、次に適用されるようにルールを再構築してください。分割変えるドライバーさらに、場合によっては、デバイス全体にわたってファイルシステムを含む単一のパーティションを作成するのではなく、USBデバイス全体にファイルシステムを作成するため、これは望ましくありません。
質問今は
udev
特定のデバイスのルール処理は、すべてのデバイスが完了するまで遅延することがあります。子供たちデバイスの一部が処理されたか、- シェルスクリプトでは、システムコールを使用してすべてを「待機」できます。子供データクエリを続行する
udev
前に完了するイベント(存在する場合!)
質問がやや長いようです。助けてくれてありがとう。
答え1
blkid
より多くの研究の終わりにinの使用法が見つかりました。ウデブルール(参照例えばこれArchLinux-Wiki 記事、残念ながらドイツ語でのみ提供されます)電話をして知りました。
blkid -o udev -p /dev/sdXn
変える
udeavdm info /dev/sdXn
-triggeredスクリプト内では、systemd
「追加」ルールに対して処理されているUSBメモリースティックサブデバイスに関する完全な情報を取得することもできます。
-p
キャッシュされた情報(例:マニュアルページまたはソースコードのblkid
)。
このオプションは、出力の先行識別子タグ(例:など)がここにないため、100%直接置換ではありませんが、-o udev
呼び出しと同様の方法で出力形式を指定します。udevadm
udevadm
E:
P: