親デバイスに問い合わせるときは、子デバイスに関する完全なudev情報を確認してください。

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分かかります）。アクションが失われました。udevudevadm info

残念ながらudev、次に適用されるようにルールを再構築してください。分割変えるドライバーさらに、場合によっては、デバイス全体にわたってファイルシステムを含む単一のパーティションを作成するのではなく、USBデバイス全体にファイルシステムを作成するため、これは望ましくありません。

質問今は

• udev特定のデバイスのルール処理は、すべてのデバイスが完了するまで遅延することがあります。子供たちデバイスの一部が処理されたか、
• シェルスクリプトでは、システムコールを使用してすべてを「待機」できます。子供データクエリを続行するudev前に完了するイベント（存在する場合！）

質問がやや長いようです。助けてくれてありがとう。