init(1M)

構文

/sbin/init [0|1|2 |3|4|5 |6|S|s |Q|q|a |b|c]

説明

init デーモンと init コマンドは汎用のプロセス生成機能です。 この主な役割はファイル /etc/inittab (inittab(4) を参照) に保存されているスクリプトからプロセスを作り出すことです。 このファイルは通常、 init が各回線に getty を生成してユーザーがログインできるようにしています。 また、特定のシステムが要求する専用のプロセスも制御します。

ブート時に、 init は、システムデーモンとして開始されます。

システムが実行されている間、 init ユーザーが生成した init は、ブートの init のアクションを誘導します。 １ 文字の引き数と受け付け、 ブート init に システムコール kill() によってシグナルを渡し、 適当なアクションを実行します。

引き数は以下のような効果を持ちます。

ブート init は 指定された時刻に 実行レベル にあるものと見なします。 実行レベルは、 システムのソフトウェアの設定であると考えることができます。 この場合、各設定では特定のグループに属するプロセスしか 存在できないものになります。 この各実行レベルに対する ブート init によって生まれたプロセスは、 inittab ファイルの中で定義されます。 ブート init は、 0-6, あるいは S か s の ８ つの実行レベルのいずれかにあります。 特権を持ったユーザーが、 init を実行すると、実行レベルを変更することができます。 この、ユーザーが生成した init は、所定のシグナルをブート init に送ります。

ブート init は、HP-UX システムの内部で、ブート手続きの最終ステップとして 起動されます。 ブート init は、まず、 システムのコンテキストなどの、必要なコンピュータに依存する初期化を行います。 つづいて、 ブート init は、 inittab ファイル を検索して、 initdefault 型のエントリーがないかを見ます (inittab(4) 参照)。 initdefault エントリーがあれば、 ブート init はそのエントリーに指定された 実行レベルを 初期実行レベルとして使います。 このエントリーが inittab に入ってなかったり、 inittab が見つからないと、 ブート init は、ユーザーに論理システムコンソール /dev/syscon から実行レベル を指定するように要求します。 S あるいは s が入れられると、 ブート init は シングルユーザー レベルになります。 このレベルは正しいフォーマットの inittab ファイルがなくてもよい唯一の実行レベルです。 inittab が存在しない場合、デフォルトでは init が入ることの可能な唯一の 実行レベルがこのシングルユーザーレベルです。

シングルユーザーレベルでは、読み取り/書き込み用に論理システムコンソール /dev/syscon がオープンされ、ただちにコマンド /usr/bin/su, /usr/bin/sh, あるいは /sbin/sh を呼び出します。 シングルユーザー実行レベルから抜け出すには ２ つのオプションのうちどちらかを選択することができます。

システムをブートするとき、 ブート init が生成したプロセスがディスプレイメッセージをシステムコンソールに送信する場合があります (inittab の内容による)。 システムのブート時にメッセージが表示されなければ、これは論理システムコンソール (/dev/syscon) が物理システムコンソール (/dev/systty) 以外のデバイスに接続していることが原因として考えられます。 このようなときは、物理システムコンソールで 削除文字 (ASCII 127) を入力してブート init に対して、強制的に /dev/syscon を /dev/systty へリンクし直すことが可能です。

ブート init が新しい 実行レベルの入力を求めてきたら、数字の 0 から 6 または英字の S または s のどれか １ つの値を入力できます。 S を入力すると、前述のようにシングルユーザーモードでブート init が動作し、さらに /dev/syscon をユーザーの端末回線にリンクするので、これを論理システムコンソールとして使用できるようになります。 このとき物理システムコンソール /dev/systty に、新しい論理システムコンソールを識別するメッセージが生成されます。

ブート init を最初に呼び出すとき、シングルユーザーステートを通常の実行ステートに切り替えるときはいつでも、論理システムコンソール /dev/syscon のステート ioctl(2) 参照) をファイル /etc/ioctl.syscon にセーブされたモードに設定します。 このファイルはシングルユーザーモードに入ると必ずブート init によって書き込まれます。 ブート init が読み取ろうとしたときにこのファイルがないと、警告をプリントしてデフォルトの設定条件になります。

0 から 6 のどれかを入力するとブート init はその番号に対応する実行レベルに入ります。 これ以外を入力すると拒否され、再度入力するように新しいプロンプトが表示されます。 ブート init がシングルユーザー以外の実行レベルに初めて入る場合は、ブート init は boot 型と bootwait 型の特殊エントリーを見つけるために、最初に inittab を走査します。 ― 入力した実行レベルがエントリーの実行レベルと一致すれば、 ― inittab の通常のプロセスを処理する前にそのエントリーを実行します。 このようにしてユーザーがシステムに入る前に、ファイルシステムのマウントのような、オペレーティングシステムの特殊な初期設定を完了します。 その 実行レベル で処理できる全エントリーを見つけるために inittab ファイルを走査します。

HP-UX の実行レベルは、以下のように定義されます。

通常、デフォルトの実行レベルは、実行レベル 3 または 4 で、システム構成によって異なります。

init が新しい実行レベル 0-6 に変更された場合、マスターシーケンススクリプト rc が実行されます。次に、 rc が、変更された実行レベルに従って、インストールされた各サブシステムに対し、開始または抹消スクリプトを実行します。より高い実行レベルに変更する場合は開始スクリプトが実行され、より低い実行レベルに変更する場合は抹消スクリプトが実行されます。rc(1M) を参照してください。

マルチユーザー環境では、通常、 ブート init がシステムの各端末ごとにプロセスを作るように inittab ファイルを設定します。

ターミナルプロセスでは、ユーザーが EOF を明示的にタイプするかハングアップが発生すると、シェルが終了します。 ブート init が、作成したプロセスが終了したことを示す子プロセス終了シグナルを受け取ると、その終了の事実と理由を utmps データベース、 /etc/utmp、 /var/adm/wtmps および /var/adm/wtmp (存在する場合) に記録します who(1) を参照)。作成したプロセスの履歴はファイル /var/adm/wtmps と /var/adm/wtmp があればそこに記録します。

inittab ファイル内の各プロセスを作るために、 ブート init は各エントリーを読み取り、作り直すことが必要なエントリーがあればそのエントリーごとに、子プロセスを fork します。 ブート init は、 inittab ファイルで指定した全プロセスを生成すると、その子プロセスの １ つが終了するか、あるいは電源異常シグナルが送信されるか、またはシステムの 実行レベルを変更するために ユーザーからの init シグナルが送信されるまで 待機します。この ３ つの条件のどれかがあてはまれば ブート init は再度 inittab ファイルを検査します。 inittab ファイルにはいつでも新しいエントリーを追加できます。しかし、 ブート init は前述の ３ 条件のどれかにあてはまるまで待機しています。 ただちに応答させたい場合は init Q (または init q) コマンドを使用すると、ブート init を即座に動作させて、実行レベルを変更せずに inittab ファイルを検査させることができます。

ブート init が電源異常シグナル (SIGPWR) を受け取り、そのときにシングルユーザーモードでない場合、ブート init は特殊 powerfail エントリーを探すために inittab ファイルを走査します。 (そのときの実行レベルで可能であれば) そのエントリーを実行してから init は次の処理に進みます。 電源異常の直後にブート init は SIGPWR を受け取っても、 ブート init の実行が再開されるまでシグナルを扱うことはできません。 実行の順序はスケジュール優先順位に基づいているので、高優先順位のプロセスを実行してから ブート init は inittab を走査し、指定された機能を実行することができます。

ブート init がユーザー init により、 実行レベル の変更要求を受け取ると、 ブート init は目的の 実行レベル で未定義の全プロセスに警告シグナル SIGTERM を送ります。 ブート init は 20 秒間待機してから、抹消シグナル SIGKILL を使って該当のプロセスを強制的に終了させます。 ブート init はそのプロセス (および子孫のプロセス) がすべて、 ブート init が初めに作成した同じプロセスグループで実行を継続していることを仮定しています。 プロセスが setpgrp() または setpgrp2() のどちらか setsid(2) および setpgrp2(2) 参照) を使用して、 その加入プロセスグループを変更したときは、このシグナルを受け取りません (このようなプロセスの一般的な例は、 ksh と csh です。 ksh(1) および csh(1) を参照)。 このようなプロセスは別々に終了させなければなりません。

ユーザー init は、 適切な特権 を持つユーザーしか実行できません。

セキュリティ機能

診断

inittab から ２ 分間に 11 回以上、１ つのエントリーを連続して再作成しようとしていることを ブート init が検知すると、コマンド文字列に誤りがあるとみなして、システムコンソール上にエラーメッセージを出して ５ 分以上経過するか、またはユーザー init からシグナルを受け取るまでこのエントリーの再作成を拒否します。 このようにして inittab ファイルにタイプエラーがあったり、 inittab 内で参照しているプログラムが削除されていても、 ブート init がシステムリソースを無駄に使用しないようにしています。

警告

ブート init は生成したプロセスと子孫のプロセスを、 ブート init が初めに作成したプロセスグループと同じプロセスグループで実行を継続しているとみなします。 そのステートを変更するとき、その加入プロセスグループ (たとえば csh および ksh) を変更するプロセスに特に注意しなければなりません。

子の ksh または csh がログインシェルで起動するとき、しばしば動作を混乱させる特殊な状況が １ つ発生する場合があります。 ブート init が、オリジナルのログインシェルを抹消させてしまう実行レベルに変更するよう要求すると、init はすでにその加入プロセスグループに変更され、オリジナルシェルの加入プロセスグループには存在しないので、シェルの子 csh または ksh プロセスは、ハングアップシグナルを受け取れなくなります。 ブート init はこの csh または ksh プロセス (またはその子) を抹消することはできません。

getty プロセスが、この前のシェルと同じ tty で遅れて開始すると、結果として ２ つのプロセス (getty とジョブをコントロールしているシェル) が tty 入力を奪い合うことになります。

このような問題を避けるためには、init ステートを変更した後に実行してはならないジョブをコントロールしているシェルを、常に手動で抹消するようにしなければなりません。 また、ユーザーのログインシェルを抹消してしまう可能性のある init ステートに変更するとき、常に低位レベルの (ログイン) シェルから ユーザー init を実行するようにしなければなりません。

init が /etc/ioctl.syscon へ書き込めなかった場合、コンソールにメッセージがログ出力されます。 それによってコンソールの設定が乱れる場合があります。

ファイル

参照

csh(1)、 ksh(1)、 login(1)、 sh(1)、 who(1)、 getty(1M)、 rc(1M)、 utmpd(1M)、 ioctl(2)、 kill(2)、 setpgid(2)、 setsid(2)、 getutsent(3C)、 updatebwdb(3C)、 inittab(4)、 security(4)、 utmp(4)

標準準拠

init: SVID2, SVID3