web-dev-qa-db-ja.com

Linuxブートプロセス、サブシステムの初期化、およびudevルールを理解していますか？

Gnome-VFSがユーザーセッション中に自動マウントを行うのとほぼ同じ方法で、ヘッドレスサーバーに外部ドライブを自動マウントするためのUDEVルールを作成しています。

起動時のルールの動作に関心があります。起動中にこれらのドライブの1つが接続される可能性は十分にあります。接続されているドライブは、適切な場所にマウントすることをお勧めします。ドライブはUSBまたはFirewireのいずれかであり、「追加」を検出するとUDEVによって起動されるシェルスクリプトからマウントされます。

これが私の質問です：

  1. UDEVが起動時にこれらのデバイスに対してmountを実行すると、システムはそれをマウントする準備ができますか？または、スクリプトのトリガーが早すぎますか？

  2. 早すぎる場合、スクリプトがシステムの準備ができていないことを通知するための良い方法は何ですか（したがって、もう一度確認する前にしばらくスリープしてください）。

  3. UDEVルールはACTION=="add"と一致します。このイベントはシステムの起動時にも発生しますか？

linuxdebianbootudevautomount
2
quack quixote

not GUIを実行しているときに（autofsを使用せずに）USBスティックを自動マウントするためにudevに詰め込んだばかりです。

  1. はいベロニカ、udevはひどく早く実行されます。

    エージェントスクリプトは、スリープ後にフォークオフして実行できます。

  2. udevadm settleは、ランレベルのチェックに加えて、ここで役立つ場合があります。

  3. action = "Add"は、ホットプラグだけでなく、起動時に実行されます。

Action = "remove"がシャットダウン時に実行されるかどうかに関係なく、これは別の色の魚です。

2
Tim Williscroft

あなたは2つの概念を混同しています。 UDEVを使用して、接続されている順序に関係なく永続的なドライブに永続的なデバイス名を割り当てる必要があります。次に、autofsを使用して、使用可能にしたい場所にオンデマンドでマウントできます。

1
Joe

私は、udevルールがこれに対する好ましい解決策ではないと思います。システムが起動したら、autofsまたはivmanを使用した方がはるかに良いと思います。udevはフックするのに非常に低いレベルであり、その上に構築されたGnome-VFSのようなツールがたくさんあります。使用および管理する。最終的には、アクセス（つまり、autofs）にマウントし、障害を検出または対応するための予測可能な高レベルのメカニズムを使用することを懸念しています。 udevレベルで作業する場合は、これらすべての懸念に自分で対処する必要があります。

0
MattyB

  1. いいえ、UDEVは、システムがマウントの準備ができるずっと前に、このスクリプトを開始します（あるとしても）。 UDEVは/etc/rcS.d/S03udevで始まり、標準のfstabマウントは/etc/rcS.d/S35mountall.shで行われます。

  2. ただ推測するよりはましです。/bin/runlevelを確認してください（ありがとう Brent ＆ rh0dium ）：

    # at boot, system runs /etc/rcS.d/S* scripts, 
#                 then /etc/rcN.d/S* scripts, N is destination runlevel
# runlevel not set at least until we're running /etc/rcN.d scripts

RUNLEVEL=`/sbin/runlevel | cut -d " " -f 2`
until [ $RUNLEVEL -ge 1 ] && [ $RUNLEVEL -le 6 ]; do
      sleep 10
      RUNLEVEL=`/sbin/runlevel | cut -d " " -f 2`
done

## run the action i want here

  3. わからない。

0
quack quixote