私のUbuntu12.04サーバーでは、infinibandインターフェイス(デバイス:mlx4_0、)まで待機するinit.dスクリプトを作成する必要があります。インターフェイス:ib0)は完全に起動し、knemカーネルモジュールがロードされるまで。
init.dスクリプトがあり、システムが起動して手動でservice myscript start
になるまで待つと機能しますが、起動時に正常にロードすると機能しません。 。起動順序99を使用していますが、これらの機能が実行されるまで待機する必要があるため、正しく起動しません。
それを達成するためのinit.d
の正しい構文は何ですか(1つのカーネルモジュールと)? # Required-Start: $remote_fs $syslog $network
のようなキーワードが必要だと思いますが、特定のインターフェイスとカーネルモジュールに適したキーワードが見つかりません。
背景の場合:initスクリプトは[〜#〜] slurm [〜#〜]、openMPIおよびinfinibandの相互作用。 [〜#〜] slurm [〜#〜]をMellanox infinibandドライバーサポートとopenMPIはこのバージョンのSLURMにリンクされています。その結果、openMPIはmellanox infinibandドライバーを直接使用しています。これは、ipob(ip over inifiniband)よりもはるかに強力です。これを行うには、システムのレジスタードメモリを使用する必要があります。これはunlimitedとして設定する必要があります。
そう:
init.dスクリプトにいくつかのlogger
出力を追加しました。実際、モジュールが稼働していることに気づきました。だから私は問題を完全には理解していません。それは奇妙で、おそらく必要ないくつかの環境変数に関連していて、初期化時にではなく、完全なユーザースペースでのみ設定されます。
この問題は、/ etc/security/limits.confで設定されたmemlock制限に関係しています。それを機能させるために私は設定しなければなりませんでした
* - memlock unlimited
root - memlock unlimited
このように、ssh接続でslurmデーモンを起動すると、すべてが機能し、デーモンを開始するのがinitプロセスである場合、デーモンを考慮しないようになります。 / etc/security/limits.confのルール。
init.d
ファイルについて具体的にはわかりませんが、デバイスの追加時にスクリプトを実行するためのudev
ルールは次のようになります。
ACTION=="add", ATTRS{idVendor}=="VID", ATTRS{idProduct}=="PID", RUN+="/path/to/executable"
デバイスが通常追加される方法とそのモジュールがロードされる方法について詳しく知るには、udevadm
を掘り下げる必要があります。 VID
とPID
の正しい値もそこにあります。
デバイスとカーネルモジュールの両方の組み合わせを受け入れますか?
はい。うーん、ダメ。多分?この質問への答えは、デバイスの追加を傍受するレベルに完全に依存します。 udev
は、デバイスを最初に検出した時点から、デバイスを完全にロードして初期化した時点まで、多くのことを行う必要があり、up。
これらのいくつかは可能性があります:
親バス/デバイス/サブシステム上のハードウェアを最初に検出します
適切なカーネルモジュールを見つけてロードする
/dev
devfs
ファイルシステムに適切なデバイス特殊ファイルを入力する
現在のデバイスが追加してすすぎ、繰り返す子デバイスを検出する
これらのアクションレベルのすべてまたはいずれかにルールを指定できます。 udevadm
trigger
またはmonitor
またはその他のいくつかのことをリアルタイムで直接実行して、これらのアクションのレベルを正確に判断することもできます。
もっと詳しく知りたい場合は、 この情報 をよく見ることをお勧めします。
これにはUpstartジョブを使用します。
# Ensures that the device is up and filesystem is too
start on filesystem and net-device-up IFACE=ib0
stop on runlevel [016]
# Ensures that module is loaded
pre-start exec modprobe -q knem
exec /path/to/exec